Method of Enabling or Disabling Verification Process

ABSTRACT

A method is provided of enabling or disabling a verification process of a first entity in response to a predetermined event. The first entity has at least one associated bit-pattern and at least one variant key. Each variant key has been generated by applying a one way function to: a base key; and one or more of the at least one bit-patterns, respectively; or one or more alternative bit patterns. Each alternative bit-pattern is based on one of the at least one bit-patterns. In the method, it is determined that the predetermined event has happened, and at least one of the first variant keys is enabled or disabled in response to the predetermined event.

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. application Ser. No.12/436,133 filed on May 6, 2009, which is a continuation of U.S.application Ser. No. 10/854,519 filed May 27, 2004, now issued U.S. Pat.No. 7,557,941, all of which are herein incorporated by reference.

FIELD OF THE INVENTION

The present invention relates to the field of secure communication.

The invention has been developed primarily to enable communicationbetween various integrated circuits in a printer, including cartridgesfor use with the printer, and will be described with reference to thisapplication. However, it will be appreciated that the invention hasbroad application in the general field, including use in software,hardware and combinations of the two.

CO-PENDING APPLICATIONS

Various methods, systems and apparatus relating to the present inventionare disclosed in the following co-pending applications filed by theapplicant or assignee of the present invention simultaneously with thepresent application:

7,374,266 7,427,117 7,448,707 7,281,330 10/854,503 7,328,956 10/854,5097,188,928 7,093,989 7,377,609 10/854,495 10/854,498 10/854,511 7,390,07110/854,525 10/854,526 7,549,715 7,252,353 10/854,515 7,267,41710/854,505 7,517,036 7,275,805 7,314,261 10/854,490 7,281,777 7,290,8527,484,831 10/854,523 10/854,527 7,549,718 10/854,520 10/854,51410/854,499 10/854,501 7,266,661 7,243,193 10/854,518

The disclosures of these co-pending applications are incorporated hereinby cross-reference.

CROSS-REFERENCES

Various methods, systems and apparatus relating to the present inventionare disclosed in the following co-pending applications filed by theapplicant or assignee of the present invention. The disclosures of allof these co-pending applications are incorporated herein bycross-reference.

7,249,108 6,566,858 6,331,946 6,246,970 6,442,525 7,346,586 09/505,9516,374,354 7,246,098 6,816,968 6,757,832 6,334,190 6,745,331 7,249,1097,509,292 10/636,283 7,416,280 7,252,366 7,488,051 7,360,865 10/727,18110/727,162 7,377,608 7,399,043 7,121,639 7,165,824 7,152,942 10/727,1577,181,572 7,096,137 7,302,592 7,278,034 7,188,282 10/727,159 10/727,18010/727,179 10/727,192 10/727,274 10/727,164 7,523,111 10/727,19810/727,158 10/754,536 10/754,938 10/727,160 6,795,215 6,859,2896,977,751 6,398,332 6,394,573 6,622,923 6,747,760 6,921,144 7,454,6177,194,629 10/791,792 7,182,267 7,025,279 6,857,571 6,817,539 6,830,1986,992,791 7,038,809 6,980,323 7,148,992 7,139,091 6,947,173

BACKGROUND

It is often desirable to enable at least one-way, and preferablytwo-way, secure communication between three or more entities. One way ofdoing this is by using a digital signature.

To create a digital signature, the data to be signed (d) is passedtogether with a secret key (k) through a key dependent one-way hashfunction (SIG). i.e. signature=SIG_(k)(d). The key dependent one-wayhash function used throughout the QA Chip Logical Interface isHMAC-SHA1, although any key dependent one-way hash function could beused.

Signatures are only of use if they can be validated. For example, QADevice A produces a signature for data and QA Device B can check if thesignature is valid for that particular data. This implies that A and Bmust share some secret information so that they can generate equivalentsignatures.

Common key signature generation is when QA Device A and QA Device Bshare the exact same key i.e. key K_(A)=key K_(B). Thus the signaturefor a message produced by A using K_(A) can be equivalently produced byB using K_(B). In other words SIG_(KA)(d)=SIG_(KB)(d) because keyK_(A)=key K_(B).

However, common key authentication has some disadvantages. For example,if a first entity wants to communicate with a series of other entities,it can share a single common key with all of them. However, this meansthat each of the entities will be able to authenticate (and emulate)messages from each other. One way around this is to give each of theother entities its own key, and store a copy of each of the keys in thefirst entity. However, where large numbers of entities are involved, anunacceptable number of keys may need to be stored in the first entity.

The problem is exacerbated when it is desirable to enable a secondentity to communicate with a third entity, where the third entity has akey to enable communication, but the second entity does not.

It would be desirable to provide a method of authenticated communicationthat addressed at least some of the problems of the prior art.

SUMMARY OF THE INVENTION

In a first aspect the present invention provides a method of enabling ordisabling a verification process of a first entity in response to apredetermined event, the first entity having at least one associatedbit-pattern and at least one variant key, each of the variant keyshaving been generated by applying a one way function to: a base key; andone or more of the at least one bit-patterns, respectively; or one ormore alternative bit patterns, each of the alternative bit-patternsbeing based on one of the at least one bit-patterns, the methodcomprising:

(a) determining that the predetermined event has happened; and(b) enabling or disabling at least one of the first variant keys inresponse to the predetermined event.

Optionally, step (a) includes disabling at least one of the variantkeys, such that the disabled at least one variant key can no longer beused to digitally sign information in that entity.

Optionally, step (a) includes disabling at least one of the variantkeys, such that the disabled at least one variant key can no longer beused to verify information signed by one or more respective base keysrelated to the disabled at least one variant key in that entity.

Optionally, the step of disabling the at least one variant key includesmodifying a status of a flag associated with that at least one variantkey.

Optionally, the step of disabling the at least one variant key includesdeleting that at least one variant key.

Optionally, the step of disabling the at least one variant key includesmodifying that at least one variant key

Optionally, the event is a predetermined point in time being reached orpassed.

Optionally, the first entity includes a plurality of the variant keys,the plurality of variant keys being based on the result of a one wayfunction applied to: a respective one of a corresponding plurality ofbase keys; and one of the at least one bit-patterns or one of the atleast one alternative bit-patterns, the method comprising:

determining that a predetermined event related to one of the variantkeys has happened; and

enabling or disabling at least one of the plurality of variant keys withwhich the predetermined event is associated.

Optionally, each base key has a corresponding sequence of predeterminedevents associated with them, the method including the steps of:

(a) determining that one of the predetermined event has happened; and(b) enabling or disabling the variant key in the sequence correspondingto predetermined event that is determined to have happened.

Optionally, the variant keys are disabled in the order of the sequenceof predetermined events.

Optionally, the sequence of events is chronological.

Optionally, each of the events includes a time being reached.

Optionally, the step of determining that one of the events has happenedincludes receiving a time from a trusted source.

Optionally, the time is a date.

Optionally, the date is determined with a resolution of a month.

Optionally, the predetermined event includes detection of compromise ofone or more of the variant keys, the method comprising disabling the oneor more variant keys detected as compromised.

Optionally, the predetermined event includes suspect compromise of oneor more of the variant keys, the method comprising disabling the one ormore variant keys suspected of being compromised.

In a second aspect the present invention provides a method ofmanufacturing second entities for use in the verification process with afirst entity, each of the first entities including at least first andsecond variant key, the first variant key having been generated byapplying a one way function to a first base key and a first bit-pattern,and the second variant key having been generated by applying a one wayfunction to a second base key and a second bit-pattern, the methodcomprising the steps of:

manufacturing a plurality of second entities for use with the firstentities, each of the second entities including at least the first basekey; and

upon the first variant key being disabled in response to one of thepredetermined event, manufacturing a plurality of third entities for usewith the first entities, each of the third entities including at leastthe second base key.

Optionally, the first variant key is automatically disabled in responseto a predetermined event.

Optionally, the method further includes the step of causing the firstvariant key to be disabled.

Optionally, the first variant key is disabled in response to a timebeing reached.

Optionally, at least some of the first entities have one or more furthervariant keys, each of the respective further variant keys having beengenerated by applying a one way function to respective further base keysand bit-patterns, each of the variant keys being enabled or disabled inresponse to respective predetermined events, the method comprising thestep of manufacturing a sequence of sets of second entities, each set ofthe second entities being manufactured such that the variant keycorresponding to its base key is enabled for the verification processduring the life of that set.

Optionally, the predetermined events are selected such that the variantkeys corresponding with the base keys of more than one of the sets areenabled at once.

Optionally, the method includes using a first entity configured toauthenticate a digital signature supplied by a second entity, whereinone of the entities includes a base key and the other of the entitiesincludes a variant key and a bit-pattern, the variant key being based onthe result of applying a one way function to the base key and thebit-pattern, the digital signature having been generated by the secondentity using its key to digitally signing at least part of data to beauthenticated, the first entity being configured to:

(a) receive the digital signature from the second entity;(b) receive the data; and(c) authenticate the digital signature based on the received data andthe first entity's key.

Optionally, the method includes using a first entity including:

a first bit-pattern;

a non-volatile memory storing resource data;

a first base key for use with at least a first variant key;

a second variant key for use with a second base key, the second variantkey being the result of a one way function applied to: the second basekey; and the first bit-pattern or a modified bit-pattern based on thefirst bit-pattern.

Optionally, the method includes using a system for enablingauthenticated communication between a first entity and at least oneother entity, the system including a second entity, wherein:

the first entity and the second entity share transport keys; and

the second entity includes at least one authentication key configured tobe transported from the second entity to the first entity using thetransport keys, the authentication key being usable to enable theauthenticated communication by the first entity.

Optionally, the method includes storing a first bit-pattern innon-volatile memory of a device, the method comprising:

(a) applying a one way function to a second bit-pattern associated withthe device, thereby to generate a first result;(b) applying a second function to the first result and the firstbit-pattern, thereby to generate a second result; and(c) storing the second result in the memory, thereby indirectly storingthe first bit-pattern.

Optionally, the method includes storing a bit-pattern in each of aplurality of devices, each of the devices having a memory, the methodcomprising, for each device:

(a) determining a first memory location; and(b) storing the bit-pattern at the first memory location;

wherein the first memory locations are different in at least a pluralityof the respective devices.

Optionally, the method includes storing at least one functionallyidentical code segment in each of a plurality of devices, each of thedevices having a memory, the method comprising, for each device:

(a) determining a first memory location; and(b) storing a first of the at least one code segments in the memory atthe first memory location;

wherein the first memory location is different in at least a pluralityof the respective devices.

Optionally, the method includes providing a sequence of nonces (R0, R1,R2, . . . ) commencing with a current seed of a sequence of seeds (x1,x2, x3, . . . ), the method comprising:

(a) applying a one-way function to the current seed, thereby to generatea current nonce;(b) outputting the current nonce;(c) using the current seed to generate a next seed in a sequence ofseeds, the seed so generated becoming the current seed; and(c) repeating steps (a) to (c) as required to generate further nonces inthe sequence of nonces.

Optionally, the method includes storing multiple first bit-patterns innon-volatile memory of a device, the method comprising, for each of thefirst bit-patterns to be stored:

(a) applying a one way function to a third bit-pattern based on a secondbit-pattern associated with the device, thereby to generate a firstresult;(b) applying a second function to the first result and the firstbit-pattern, thereby to generate a second result; and(c) storing the second result in the memory, thereby indirectly storingthe first bit-pattern;

wherein the third bit-patterns used for the respective firstbit-patterns are relatively unique compared to each other.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1. Single SoPEC A4 Simplex system

FIG. 2. Dual SoPEC A4 Simplex system

FIG. 3. Dual SoPEC A4 Duplex system

FIG. 4. Dual SoPEC A3 simplex system

FIG. 5. Quad SoPEC A3 duplex system

FIG. 6. SoPEC A4 Simplex system with extra SoPEC used as DRAM storage

FIG. 7. SoPEC A4 Simplex system with network connection to Host PC

FIG. 8. Document data flow

FIG. 9. Pages containing different numbers of bands

FIG. 10. Contents of a page band

FIG. 11. Page data path from host to SoPEC

FIG. 12. Page structure

FIG. 13. SoPEC System Top Level partition

FIG. 14. Proposed SoPEC CPU memory map (not to scale)

FIG. 15. Possible USB Topologies for Multi-SoPEC systems

FIG. 16. CPU block diagram

FIG. 17. CPU bus transactions

FIG. 18. State machine for a CPU subsystem slave

FIG. 19. Proposed SoPEC CPU memory map (not to scale)

FIG. 20. MMU Sub-block partition, external signal view

FIG. 21. MMU Sub-block partition, internal signal view

FIG. 22. DRAM Write buffer

FIG. 23. DIU waveforms for multiple transactions

FIG. 24. SoPEC LEON CPU core

FIG. 25. Linking Printhead Concept

FIG. 26. Equivalent signature generation

FIG. 27. An allocation of words in memory vectors

FIG. 28. Transfer and rollback process

DETAILED DESCRIPTION OF PREFERRED EMBODIMENT

Also throughout this description, “printhead module” and “printhead” areused somewhat interchangeably. Technically, a “printhead” comprises oneor more “printhead modules”, but occasionally the former is used torefer to the latter. It should be clear from the context which meaningshould be allocated to any use of the word “printhead”.

A SoPEC ASIC (Small office home office Print Engine Controller) suitablefor use in price sensitive SoHo printer products is described. The SoPECASIC is intended to be a relatively low cost solution for linkingprinthead control, replacing the multichip solutions in larger moreprofessional systems with a single chip. The increased costcompetitiveness is achieved by integrating several systems such as amodified PEC1 printing pipeline, CPU control system, peripherals andmemory sub-system onto one SoC ASIC, reducing component count andsimplifying board design. SoPEC contains features making it suitable formultifunction or “all-in-one” devices as well as dedicated printingsystems.

Basic features of the preferred embodiment of SoPEC include:

-   -   Continuous 30 ppm operation for 1600 dpi output at A4/Letter.    -   Linearly scalable (multiple SoPECs) for increased print speed        and/or page width.    -   192 MHz internal system clock derived from low-speed crystal        input    -   PEP processing pipeline, supports up to 6 color channels at 1        dot per channel per clock cycle    -   Hardware color plane decompression, tag rendering, halftoning        and compositing    -   Data formatting for Linking Printhead    -   Flexible compensation for dead nozzles, printhead misalignment        etc.    -   Integrated 20 Mbit (2.5 MByte) DRAM for print data and CPU        program store    -   LEON SPARC v8 32-bit RISC CPU    -   Supervisor and user modes to support multi-threaded software and        security    -   1 kB each of I-cache and D-cache, both direct mapped, with        optimized 256-bit fast cache update.    -   1×USB2.0 device port and 3×USB2.0 host ports (including        integrated PHYs)    -   Support high speed (480 Mbit/sec) and full speed (12 Mbit/sec)        modes of USB2.0    -   Provide interface to host PC, other SoPECs, and external devices        e.g. digital camera    -   Enable alternative host PC interfaces e.g. via external        USB/ethernet bridge    -   Glueless high-speed serial LVDS interface to multiple Linking        Printhead chips    -   64 remappable GPIOs, selectable between combinations of        integrated system control components:    -   2×LSS interfaces for QA chip or serial EEPROM    -   LED drivers, sensor inputs, switch control outputs    -   Motor controllers for stepper and brushless DC motors    -   Microprogrammed multi-protocol media interface for scanner,        external RAM/Flash, etc.    -   112-bit unique ID plus 112-bit random number on each device,        combined for security protocol support    -   IBM Cu-11 0.13 micron CMOS process, 1.5V core supply, 3.3V IO.    -   208 pin Plastic Quad Flat Pack

The SoPEC device can be used in several printer configurations andarchitectures.

In the general sense, every preferred embodiment SoPEC-based printerarchitecture will contain:

-   -   One or more SoPEC devices.    -   One or more linking printheads.    -   Two or more LSS busses.    -   Two or more QA chips.    -   Connection to host, directly via USB2.0 or indirectly.    -   Connections between SoPECs (when multiple SoPECs are used).

The Host PC rasterizes and compresses the incoming document on a page bypage basis. The page is restructured into bands with one or more bandsused to construct a page. The compressed data is then transferred to theSoPEC device directly via a USB link, or via an external bridge e.g.from ethernet to USB. A complete band is stored in SoPEC embeddedmemory. Once the band transfer is complete the SoPEC device reads thecompressed data, expands the band, normalizes contone, bi-level and tagdata to 1600 dpi and transfers the resultant calculated dots to thelinking printhead.

The SoPEC device can print a full resolution page with 6 color planes.Each of the color planes can be generated from compressed data throughany channel (either JPEG compressed, bi-level SMG4 fax compressed, tagdata generated, or fixative channel created) with a maximum number of 6data channels from page RIP to linking printhead color planes.

The mapping of data channels to color planes is programmable. Thisallows for multiple color planes in the printhead to map to the samedata channel to provide for redundancy in the printhead to assist deadnozzle compensation.

Also a data channel could be used to gate data from another datachannel. For example in stencil mode, data from the bilevel data channelat 1600 dpi can be used to filter the contone data channel at 320 dpi,giving the effect of 1600 dpi edged contone images, such as 1600 dpicolor text.

The SoPEC device typically stores a complete page of document data onchip. The amount of storage available for compressed pages is limited to2 Mbytes, imposing a fixed maximum on compressed page size. SoPEC wouldnot be capable of printing worst case pages unless they are split intobands and printing commences before all the bands for the page have beendownloaded. The page sizes in the table are shown for comparisonpurposes and would be considered reasonable for a professional levelprinting system. The SoPEC device is aimed at the consumer level andwould not be required to print pages of that complexity. If a documentwith more complex pages is required, the page RIP software in the hostPC can determine that there is insufficient memory storage in the SoPECfor that document. In such cases the RIP software can take two coursesof action:

-   -   It can increase the compression ratio until the compressed page        size will fit in the SoPEC device, at the expense of print        quality, or    -   It can divide the page into bands and allow SoPEC to begin        printing a page band before all bands for that page are        downloaded.

Once SoPEC starts printing a page it cannot stop; if SoPEC consumescompressed data faster than the bands can be downloaded a bufferunderrun error could occur causing the print to fail. A buffer underrunoccurs if a line synchronisation pulse is received before a line of datahas been transferred to the printhead.

Other options which can be considered if the page does not fitcompletely into the compressed page store are to slow the printing or touse multiple SoPECs to print parts of the page. Alternatively, a numberof methods are available to provide additional local page data storagewith guaranteed bandwidth to SoPEC, for example a Storage SoPEC.

The SoPEC is a page rendering engine ASIC that takes compressed pageimages as input, and produces decompressed page images at up to 6channels of bi-level dot data as output. The bi-level dot data isgenerated for the Memjet linking printhead. The dot generation processtakes account of printhead construction, dead nozzles, and allows forfixative generation.

A single SoPEC can control up to 12 linking printheads and up to 6 colorchannels at >10,000 lines/sec, equating to 30 pages per minute. A singleSoPEC can perform full-bleed printing of A4 and Letter pages. The 6channels of colored ink are the expected maximum in a consumer SOHO, oroffice Memjet printing environment:

-   -   CMY, for regular color printing.    -   K, for black text, line graphics and gray-scale printing.    -   IR (infrared), for Netpage-enabled applications.    -   F (fixative), to enable printing at high speed. Because the        Memjet printer is capable of printing so fast, a fixative may be        required on specific media types (such as calendared paper) to        enable the ink to dry before the page touches a previously        printed page. Otherwise the pages may bleed on each other. In        low speed printing environments, and for plain and photo paper,        the fixative is not be required.

SoPEC is color space agnostic. Although it can accept contone data asCMYX or RGBX, where X is an optional 4th channel (such as black), italso can accept contone data in any print color space. Additionally,SoPEC provides a mechanism for arbitrary mapping of input channels tooutput channels, including combining dots for ink optimization,generation of channels based on any number of other channels etc.However, inputs are typically CMYK for contone input, K for the bi-levelinput, and the optional Netpage tag dots are typically rendered to aninfra-red layer. A fixative channel is typically only generated for fastprinting applications.

SoPEC is resolution agnostic. It merely provides a mapping between inputresolutions and output resolutions by means of scale factors. Theexpected output resolution is 1600 dpi, but SoPEC actually has noknowledge of the physical resolution of the linking printhead.

SoPEC is page-length agnostic. Successive pages are typically split intobands and downloaded into the page store as each band of information isconsumed and becomes free.

SoPEC provides mechanisms for synchronization with other SoPECs. Thisallows simple multi-SoPEC solutions for simultaneous A3/A4/Letter duplexprinting. However, SoPEC is also capable of printing only a portion of apage image. Combining synchronization functionality with partial pagerendering allows multiple SoPECs to be readily combined for alternativeprinting requirements including simultaneous duplex printing and wideformat printing.

The required printing rate for a single SoPEC is 30 sheets per minutewith an inter-sheet spacing of 4 cm. To achieve a 30 sheets per minuteprint rate, this requires:

-   -   300 mm×63 (dot/mm)/2 sec=105.8 seconds per line, with no        inter-sheet gap.    -   340 mm×63 (dot/mm)/2 sec=93.3 seconds per line, with a 4 cm        inter-sheet gap.

A printline for an A4 page consists of 13824 nozzles across the page. Ata system clock rate of 192 MHz, 13824 dots of data can be generated in69.2 seconds. Therefore data can be generated fast enough to meet theprinting speed requirement.

Once generated, the data must be transferred to the printhead. Data istransferred to the printhead ICs using a 288 MHz clock ( 3/2 times thesystem clock rate). SoPEC has 6 printhead interface ports running atthis clock rate. Data is 8b/10b encoded, so the throughput per port is0.8×288=230.4 Mb/sec. For 6 color planes, the total number of dots perprinthead IC is 1280×6=7680, which takes 33.3 seconds to transfer. With6 ports and 11 printhead ICs, 5 of the ports address 2 ICs sequentially,while one port addresses one IC and is idle otherwise. This means alldata is transferred on 66.7 seconds (plus a slight overhead). Thereforeone SoPEC can transfer data to the printhead fast enough for 30 ppmprinting.

From the highest point of view the SoPEC device consists of 3 distinctsubsystems

-   -   CPU Subsystem    -   DRAM Subsystem    -   Print Engine Pipeline (PEP) Subsystem

See FIG. 13 for a block level diagram of SoPEC.

The CPU subsystem controls and configures all aspects of the othersubsystems. It provides general support for interfacing andsynchronising the external printer with the internal print engine. Italso controls the low speed communication to the QA chips. The CPUsubsystem contains various peripherals to aid the CPU, such as GPIO(includes motor control), interrupt controller, LSS Master, MMI andgeneral timers. The CPR block provides a mechanism for the CPU topowerdown and reset individual sections of SoPEC. The UDU and UHUprovide high-speed USB2.0 interfaces to the host, other SoPEC devices,and other external devices. For security, the CPU supports user andsupervisor mode operation, while the CPU subsystem contains somededicated security components.

The DRAM subsystem accepts requests from the CPU, UHU, UDU, MMI andblocks within the PEP subsystem. The DRAM subsystem (in particular theDIU) arbitrates the various requests and determines which request shouldwin access to the DRAM. The DIU arbitrates based on configuredparameters, to allow sufficient access to DRAM for all requesters. TheDIU also hides the implementation specifics of the DRAM such as pagesize, number of banks, refresh rates etc.

The Print Engine Pipeline (PEP) subsystem accepts compressed pages fromDRAM and renders them to bi-level dots for a given print line destinedfor a printhead interface that communicates directly with up to 12linking printhead ICs.

The first stage of the page expansion pipeline is the CDU, LBD and TE.The CDU expands the JPEG-compressed contone (typically CMYK) layer, theLBD expands the compressed bi-level layer (typically K), and the TEencodes Netpage tags for later rendering (typically in IR, Y or K ink).The output from the first stage is a set of buffers: the CFU, SFU, andTFU. The CFU and SFU buffers are implemented in DRAM.

The second stage is the HCU, which dithers the contone layer, andcomposites position tags and the bi-level spot0 layer over the resultingbi-level dithered layer. A number of options exist for the way in whichcompositing occurs. Up to 6 channels of bi-level data are produced fromthis stage. Note that not all 6 channels may be present on theprinthead. For example, the printhead may be CMY only, with K pushedinto the CMY channels and IR ignored. Alternatively, the position tagsmay be printed in K or Y if IR ink is not available (or for testingpurposes).

The third stage (DNC) compensates for dead nozzles in the printhead bycolor redundancy and error diffusing dead nozzle data into surroundingdots.

The resultant bi-level 6 channel dot-data (typically CMYK-IRF) isbuffered and written out to a set of line buffers stored in DRAM via theDWU.

Finally, the dot-data is loaded back from DRAM, and passed to theprinthead interface via a dot FIFO. The dot FIFO accepts data from theLLU up to 2 dots per system clock cycle, while the PHI removes data fromthe FIFO and sends it to the printhead at a maximum rate of 1.5 dots persystem clock cycle.

Manufacturers of systems that require consumables (such as laserprinters that require toner cartridges) have addressed the problem ofauthenticating consumables with varying levels of success. Most haveresorted to specialized packaging that involves a patent. However thisdoes not stop home refill operations or clone manufacture in countrieswith weak industrial property protection. The prevention of copying isimportant to prevent poorly manufactured substitute consumables fromdamaging the base system. For example, poorly filtered ink may clogprint nozzles in an ink jet printer, causing the consumer to blame thesystem manufacturer and not admit the use of non-authorized consumables.

In addition, some systems have operating parameters that may be governedby a license. For example, while a specific printer hardware setup mightbe capable of printing continuously, the license for use may onlyauthorise a particular print rate. The printing system would ideally beable to access and update the operating parameters in a secure,authenticated way, knowing that the user could not subvert the licenseagreement.

Furthermore, legislation in certain countries requires consumables to bereusable. This slightly complicates matters in that refilling must bepossible, but not via unauthorized home refill or clone refill means.

To address these authentication problems, this document defines the QAChip Logical Interface, which provides authenticated manipulation of asystem's operating and consumable parameters. The interface is describedin terms of data structures and the functions that manipulate them,together with examples of use. While the descriptions and examples aretargeted towards the printer application, they are equally applicable inother domains. The QA Chip Logical Interface is now described.

The QA Chip Logical Interface is a logical interface, and is thereforeimplementation independent. Although this document does not coverimplementation details on particular platforms, expected implementationsinclude:

-   -   Software only    -   Off-the-shelf cryptographic hardware    -   ASICs, such as SBR4320 [2] and SOPEC [5] for physical insertion        into printers and ink cartridges    -   Smart cards

An instance of a QA Chip Logical Interface (on any platform) is a QADevice.

QA Devices cannot talk directly to each other. A System is a logicalentity which has one or more QA Devices connected logically (orphysically) to it, and calls the functions on those QA Devices.

From the point of view of a QA Device receiving commands, System cannotinherently be trusted i.e. a given QA Device cannot tell if the Systemis trustworthy or not. System can, however, be constructed within atrustworthy environment (such as a SoPEC or within another physicallysecure computer system), and in these cases System can trust itself.

Digital signatures are used throughout the authentication protocols ofthe QA Chip Logical Interface. A signature is produced by passing dataplus a secret key through a keyed hash function. The signature provesthat the data was signed by someone who knew the secret key.

The signature function used throughout the QA Chip Logical Interface isHMAC-SHA1.

When a System is constructed within a physically/logically secureenvironment, then System itself is trusted, and any software/hardwarerunning within that secure environment is trusted. A Trusted QA Deviceis simply a QA Device that resides within the same secure environmentthat System also resides in, and can therefore be trusted by System.This means that it is not possible for an attacker to subvert thecommunication between the System and the Trusted QA Device, or toreplace the functionality of a QA Device by some other functionality. ATrusted QA Device enables a System to extend trust to external QADevices. An example of a Trusted QA Device is a body of software insidea digitally signed program.

An External untrusted QA Device is a QA Device that resides external tothe trusted environment of the system and is therefore untrusted. Thepurpose of the QA Chip Logical Interface is to allow the externaluntrusted QA Devices to become effectively trusted. This is accomplishedwhen a Trusted QA Device shares a secret key with the external untrustedQA Device, or with a Translation QA Device (see below).

In a printing application, external untrusted QA Devices would typicallybe instances of SBR4320 implementations located in a consumable or theprinter.

A Translation QA Device is used to translate signatures between QADevices and extend effective trust when secret keys are not directlyshared between QA Devices.

As an example, if a message is sent from QA Device A to QA Device C, butA and C don't share a secret key, then under normal circumstances Ccannot trust the message because a signature generated by A cannot beverified by C. However if A and B share secret 1, and B and C sharesecret 2, and B is allowed to translate signatures for certain messagessent between secret 1 and secret 2, then B can be used as a TranslationQA Device to allow those messages to be sent between A and C.

A Consumable QA Device is an external untrusted QA Device located in aconsumable. It typically contains details about the consumable,including how much of the consumable remains.

In a printing application the consumable QA Device is typically found inan ink cartridge and is referred to as an Ink QA Device, or simply InkQA since ink is the most common consumable for printing applications.However, other consumables in printing applications include media andimpression counts, so consumable QA Device is more generic.

An Operating Parameter QA Device is an external untrusted device locatedwithin the infrastructure of a product, and contains at least some ofthe operating parameters of the application. Unlike the Trusted QADevice, an Operating Parameter QA Device is in a physically/logicallyuntrusted section of the overall hardware/software.

An example of an Operating Parameter QA Device in a SoPEC-based printersystem is the PrinterQA Device (or simply PrinterQA), that contains theoperating parameters of the printer. The PrinterQA contains OEM andprinter model information that indirectly specifies the non-upgradeableoperating parameters of the printer, and also contains the upgradeableoperating parameters themselves.

A Value Upgrader QA Device contains the necessary functions to allow asystem to write an initial value (e.g. an ink amount) into another QADevice, typically a consumable QA Device. It also allows a system torefill/replenish a value in a consumable QA Device after use.

Whenever a value upgrader QA Device increases the amount of value inanother QA Device, the value in the value upgrader QA Device iscorrespondingly decreased. This means the value upgrader QA Devicecannot create value—it can only pass on whatever value it itself hasbeen issued with. Thus a value upgrader QA Device can itself bereplenished or topped up by another value upgrader QA Device.

An example of a value upgrader is an Ink Refill QA Device, which is usedto fill/refill ink amount in an Ink QA Device.

A Parameter Upgrader QA Device contains the necessary functions to allowa system to write an initial parameter value (e.g. a print speed) intoanother QA Device, e.g. an Operating Parameter QA Device. It also allowsa system to change that parameter value at some later date.

A parameter upgrader QA Device is able to perform a fixed number ofupgrades, and this number is effectively a consumable value. Thus thenumber of available upgrades decreases by 1 with each upgrade, and canbe replenished by a value upgrader QA Device.

Secret transport keys are inserted into QA Devices during instantiation(e.g. manufacture). These keys must be replaced by the final secret keyswhen the purpose of the QA Device is known. The Key Replacement QADevice implements all necessary functions for replacing keys in other QADevices.

An Authenticated Read is a read of data from a non-trusted QA Devicethat also includes a check of the signature. When the System determinesthat the signature is correct for the returned data (e.g. by asking aTrusted QA Device to test the signature) then the System is able todetermine that the data has not been tampered en route from the read,and was actually stored on the non-trusted QA Device.

An authenticated write is a write to the data storage area in a QADevice where the write request includes both the new data and asignature. The signature is based on a key that has write accesspermission to the region of data in the QA Device, and proves to thereceiving QA Device that the writer has the authority to perform thewrite. For example, a Value Upgrader Refilling Device is able toauthorize a system to perform an authenticated write to upgrade aConsumable QA Device (e.g. to increase the amount of ink in an Ink QADevice).

The QA Device that receives the write request checks that the signaturematches the data (so that it hasn't been tampered with en route) andalso that the signature is based on the correct authorization key.

An authenticated write can be followed by an authenticated read toensure (from the system's point of view) that the write was successful.

A non-authenticated write is a write to the data storage area in a QADevice where the write request includes only the new data (and nosignature). This kind of write is used when the system wants to updateareas of the QA Device that have no access-protection.

The QA Device verifies that the destination of the write request hasaccess permissions that permit anyone to write to it. If access ispermitted, the QA Device simply performs the write as requested.

A non-authenticated write can be followed by an authenticated read toensure (from the system's point of view) that the write was successful.

Authorized modification of data refers to modification of data viaauthenticated writes.

The primary purpose of a QA Device is to securely holdapplication-specific data. For example if the QA Device is a ConsumableQA Device for a printing application it may store ink characteristicsand the amount of ink remaining.

For secure manipulation of data:

-   -   Data must be clearly identified (includes typing of data).    -   Data must have clearly defined access criteria and permissions.    -   Data must be able to be transferred securely from one QA Device        to another, through a potentially insecure environment.

In addition, each QA Device must be capable of storing multiple dataelements, where each data element is capable of being manipulated in adifferent way to represent the intended use of that data element. Forconvenience, a data element is referred to as a field.

Each QA Device requires an identifier that allows unique identificationof that QA Device by external systems, ensures that messages arereceived by the correct QA Device, and ensures that the same device canbe used across multiple transactions.

Strictly speaking, the identifier only needs to be unique within thecontext of a key, since QA Devices only accept messages that areappropriately signed. However it is more convenient to have the instanceidentifier completely unique, as is the case with this design.

In certain circumstances it is useful for a Trusted QA Device to assumethe instance identifier of an external untrusted QA Device in order tobuild a local trusted form of the external QA Device. It is theresponsibility of the System to ensure that the correct device is usedfor particular messages. As an example, a Trusted QA Device in aSoPEC-based printing system has the same instance identifier as theexternal (untrusted) Printer QA so that the System can accessfunctionality in the Trusted QA instead of the external untrustedPrinter QA. The identifier functionality is provided by ChipId.

ChipId is the unique 64-bit QA Device identifier. The ChipId is set whenthe QA Device is instantiated, and cannot be changed during the lifetimeof the QA Device.

A 64-bit ChipId gives a maximum of 1844674 trillion unique QA Devices.

Each QA Device contains a number of secret keys that are used forsignature generation and verification. These keys serve three basicfunctions:

-   -   For reading, where they are used to verify that the read data        came from the particular    -   QA Device and was not altered en route.    -   For writing, where they are used to authorise modification of        data.    -   For transporting keys, where they are used in the process of        encrypting and transporting new keys into the QA Device.

All of these functions are achieved by signature generation; a key isused to generate a signature for subsequent transmission from thedevice, and to generate a signature to compare against a receivedsignature. The transportation function is additionally achieved byencryption.

The number of secret keys in a QA Device is given by NumKeys, and has amaximum value of 256, i.e. the number of keys for a particularimplementation may be less than this. For convenience, we refer to a QADevice as having NumKeys keyslots, where each keyslot contains a singlekey. Thus the nth keyslot contains the nth key (where n has the range 0to NumKeys-1). The keyslot concept is useful because a keyslot containsnot only the bit-pattern of the secret key, but also additionalinformation related to the secret key and its use within the QA Device.The term Keyslot[n].xxx is used to describe the element named xxx withinKeyslot n.

Each key is referred to as K, and the subscripted form K_(n) refers tothe key in the nth keyslot. Thus K_(n)=Keyslot[n].K.

The length of each key is 160 bits. 160 bits was chosen because theoutput signature length from the signature generation function(HMAC-SHA1) is 160 bits, and a key longer than 160-bits does not add tothe security of the function.

The security of the digital signatures relies upon keys being keptsecret. To safeguard the security of each key, keys should be generatedin a way that is not deterministic. Ideally the bit pattern representinga particular key should be a physically generated random number,gathered from a physically random phenomenon. Each key is initiallyprogrammed during QA Device instantiation.

For the convenience of the System, each key has a corresponding 18-bitKeyId which can be read to determine the identity or label of the keywithout revealing the value of the key itself. Since the relationshipbetween keys and KeyIds is 1:1 (they are both stored in the samekeyslot), a system can read all the KeyIds from a QA Device and knowwhat key is stored in each of the keyslots. A KeyId of INVALID_KEYID(=0) is the only predefined id, and indicates that the key is invalidand should not be used, although the QA Device itself will notspecifically prevent its use. From a system perspective, the bit patternof a key is undefined when KeyId=INVALID_KEYID, and so cannot beguaranteed to match another key whose KeyId is also INVALID_KEYID. Thebit pattern for such a key should be set to a random bit pattern for thephysical security of any other keys present in the QA Device.

To create a digital signature, the data to be signed (d) is passedtogether with a secret key (k) through a key dependent one-way hashfunction (SIG). i.e. signature=SIG_(k)(d). The key dependent one-wayhash function used throughout the QA Chip Logical Interface isHMAC-SHA1, although from a theoretical sense any key dependent one-wayhash function could be used.

Signatures are only of use if they can be validated i.e. QA Device Aproduces a signature for data and QA Device B can check if the signatureis valid for that particular data. This implies that A and B must sharesome secret information so that they can generate equivalent signatures.

Common key signature generation is when QA Device A and QA Device Bshare the exact same key i.e. key K_(A)=key K_(B). Thus the signaturefor a message produced by A using K_(A) can be equivalently produced byB using K_(B). In other words SIG_(KA)(d)=SIG_(KB)(d) because keyK_(A)=key K_(B).

Variant key signature generation is when QA Device B holds a base key,and QA Device A holds a variant of that key such that K_(A)=owf(K_(B),U_(A)) where owf is a one-way function based upon the base key (K_(B))and a unique number in A (U_(A)). A one-way function is required tocreate K_(A) from K_(B) or it would be possible to derive K_(B) if K_(A)were exposed. Thus A can produce SIG_(KA)(message), but for B to producean equivalent signature B must produce K_(A) by being told U_(A) from Aand using B's base key K_(B). K_(A) is referred to as a variant key andK_(B) is referred to as the base key. Therefore, B can produceequivalent signatures from many QA Devices, each of which has its ownunique variant of K_(B). Since ChipId is unique to a given QA Device, weconveniently use that as U_(A).

Common key signature generation is used when A and B are effectivelyequally available¹ to an attacker. Variant key signature generation isused when B is not readily available to an attacker, and A is readilyavailable to an attacker. If an attacker is able to determine K_(A),they do not know K_(A) for any other QA Device of class A, and they arenot able to determine K_(B). ¹ The term “equally available” is relative.It typically means that the ease of availability of both are theeffectively the same, regardless of price (e.g. both A and B arecommercially available and effectively equally easy to come by).

When two or more devices share U_(A) (in our implementation, U_(A) isChipId), then their variant keys can be effectively treated as commonkeys for signatures passed between them, but as variant keys when passedto other devices.

The QA Device producing or testing a signature needs to know if it mustuse the common or variant means of signature generation. Likewise, whena key is stored in a QA Device, the status of the key (whether it is abase or variant key) must be stored in the keyslot along with the keyfor future reference.

Therefore each keyslot contains a 1-bit Variant flag to hold the statusof the key in that keyslot:

-   -   Variant=0 means the key in the keyslot is a base/common key    -   Variant=1 means the key in the keyslot is a variant key

The QA Device itself doesn't directly use the Variant setting. Instead,the System reads the value of variant from the desired keyslots in thetwo QA Devices (one QA Device will produce the signature, the other willcheck the signature) and informs the signature generation function andsignature checking functions whether or not to use base or variantsignature generation for a particular operation.

It is assumed in equivalent signature generation between 4 QA Devices A,B, C that each device has a single keyslot. KeySlot.KeyId of all fourkeys are the same i.eKeySlot[A].KeyId=KeySlot[B].KeyId=KeySlot[C].KeyId=KeySlot[D].KeyId.

If KeySlot[A].Variant=0 and KeySlot[B].Variant=0, then a signatureproduced by A, can be equivalently produced by B because K_(A)=K_(B).

If KeySlot[B].Variant=0 and KeySlot[C].Variant=1, then a signatureproduced by C, can be equivalently produced by B because K_(C)=f (K_(B),ChipId_(C)). Note that B must be told ChipId_(C) for this to bepossible.

If KeySlot[C].Variant=1 and KeySlot[D].Variant=1, then a signatureproduced by C, cannot be equivalently produced by D unless both QADevices have the same U_(A) (i.e. they must share the same ChipIdentifier) While C and D will typically not share a ChipId, in certaincircumstances the System can read a QA Device's Chip Identifier andinstall it into another QA Device. Then, using key transport mechanisms,the two QA Devices can come to share a common variant key, and canthence generate and check signatures with each other.

If KeySlot[D].Variant=1 and KeySlot[A].Variant=0, then a signatureproduced by D, can be equivalently produced by A because K_(D)=f (K_(A),ChipId_(D)).

While it is theoretically possible that a system could permit each keyto be used to perform all of these tasks, in most cases it is a securityrisk to allow this.

If any key can be used to transport any other key out of a QA Device,then a compromise of a single key means a compromise of all keys. Thereason is that the compromised key can be used by an attacker totransport all other keys out of a QA Device. Some QA Devices (such asKey Replacement QA Devices) are specifically required to transport keys,while others (such as those devices used in consumables) should not evertransport their keys out.

During manufacture it is not always possible to know the final intendedapplication for a given QA Device. For example, one may end up at OEM1while another is destined for OEM2. To decouple manufacture frominstallation of QA Devices, it is useful to place temporary batch keysinto the QA Devices. Each of these keys should be replaceable by adifferent batch key or a final application key, but during theirtemporary existence these keys must not be capable of authenticatingsignatures writes of data. Thus they act as a transport key.

Likewise, in the Key Replacement QA Device, there is a need todifferentiate between final use for a key in a QA Device, and storage ofa key in one QA Device for subsequent injection into another. Forexample, a key may be a transport key when stored in QA Device A, andalthough we want to store that same key in a Key Replacement QA Device Bfor future injection into A, we do not want that key to be used totransport keys from B. Thus, if a key is not in its final intendedkeyslot, then it should have no abilities in that QA Device other thanbeing transported out, and the intended use of the key (for examplewhether or not it will be a transport key when installed in its finaldestination) needs to be associated with that key.

From a security point of view there should be a time when a key in agiven keyslot can be guaranteed to be in its final intended form i.e. itcannot be replaced later. If a key could be replaced at any time,attackers could potentially launch a denial of service attack byreplacing keys with garbage, or could replace a key with one of theirown choice. As an example, suppose keys k1 and k2 are both used to readvalue from a QA Device, write value to the QA Device, and to transportnew keys into the QA Device. If either k1 or k2 is compromised, then thecompromised key could be used to transport keys of choice to replaceboth keys and create value in the QA Device.

Therefore each keyslot contains 3 1-bit flags as follows:

-   -   KeyType: whether the key is a TransportKey (0) to be used for        key transport and signing reads of key meta-information, or if        it is a DataKey (1) to be used for signing data as well as key        meta-information    -   TransportOut: whether or not the key can be transported out from        this QA Device    -   UseLocally: whether or not the key is for use locally within        this QA Device or not. For transport keys this means whether or        not the transport key can be used to transport another key out        from this QA Device.

The following examples assume 3 bits xyz are interpreted as:

-   -   x=KeyType    -   y=TransportOut    -   z=UseLocally

A freshly manufactured QA Device A will most likely have the 3 bits foreach keyslot set to 000 so that all the keys are replaceable.

To replace one of A's keys (k1) by another batch key (k2), keyreplacement QA Device B is required where B typically contains k1 with 3bits set to 001, and k2 with 3 bits set to 010. After k2 has beentransferred into A, the 3 bits within A will be now set to 000. Thus k2cannot be used or replaced within B, but can be replaced within A.

To replace one of A's keys (k1) by a final use data key (k2), keyreplacement QA Device B is required where B typically contains k1 with 3bits set to 001, and k2 with 3 bits set to 110. After k2 has beentransferred into A, the 3 bits within A will be now set to 101. Thus k2can be used within A but not B, and cannot be transported out of A.

Although there are KeyNum keyslots in a QA Device, not all keyslots maybe required for a given application. For example, a QA Device may supply256 keyslots, but only 2 keys may be required for a particularapplication. The remaining keyslots need to be invalidated so theycannot be used as a reference for signature checking or signaturegeneration.

When QA Device A has a keyslot with KeyType, TransportOut, andUseLocally set to 000, then the key in that keyslot can be replaced.

To invalidate the keyslot in A where k1 is currently residing so that nofurther keys can ever be stored in that keyslot, key replacement QADevice B is required where B typically contains:

k1 with 3 bits set to 001

a base key k2 with 3 bits set to 110 and a KeyId of 0

After k2 has been transferred into A as a variant key, the 3 bits withinA will be now set to 100. Thus k2 cannot be used within A, cannot betransported out of A, and cannot be replaced. Moreover, being a variantkey in A, k2 will be different for each instance of A and will thereforebe contribute to the entropy of A. Any system reading the KeyIds thatare present in A will see that the keyslot contains a key whose keyId is0 (and is therefore invalid) and whose 2-bits specify that the keycannot be used.

Over the lifetime of a product, it may be desirable to retire a givenkey from use, either because of compromise or simply because it has beenused for a specific length of time (and therefore to reduce the risk ofcompromise). Therefore the key in a keyslot needs to be invalidated bysome means so that it cannot be used any more as a reference forsignature checking or signature generation. From an audit-trail point ofview, although a key has been retired from use, it is convenient toretain the key meta-information so that a System can know which keyshave been retired.

In theory, a special command could be available in each QA Device toallow the caller to transform the KeyType, TransportOut, and UseLocallysettings for a keyslot from some value to 100. The key in that slotwould then be non-transportable non-usable, and therefore invalid.However it would not be possible to know the previous setting for the 3bits once the key had become invalid.

It is therefore desirable to have a boolean in each keyslot that can beset to make a particular key invalid. If a key has been marked asinvalid, then TransportOut and UseLocally are ignored and treated as 0,and the key cannot be replaced.

However, a single bit representation of this boolean over-complicates4320-based implementations of QA Devices in that it is not possible toset a single bit in shadowed mode on a 4320 device (to change a key fromvalid to invalid). Instead, the page containing the key would need to beerased and the key reconstructed, tasks which need to take place duringinitial key replacement during manufacture, but which should not need totake place after the keys are all finalised.

Therefore each keyslot contains a 4-bit boolean (which should benybble-aligned within the keyslot data structure) referred to asInvalid, where 0000 represents a valid key in the keyslot, and non-zerorepresents an invalid key. A specific command (Invalidate Key) exists inthe QA Logical Interface to allow a caller to invalidate a previouslyvalid key.

If Invalid is set to a non-zero value, then the key is not usedregardless of the settings for KeyType, TransportOut, and UseLocally.

In general each QA Device contains a number of data elements (eachelement referred to as a field), each of which can be operated upon byone or more keys. In the general case of an arbitrary device containingkeys and fields, it is useful to have a set of permissions for each keyon each field. For example, key 1 may have read-only permissions onfield 1, but read/write permissions on field 2 and read/decrement-onlypermissions on field 3.

Although it can cater for all possibilities, a general scheme has sizeand complexity difficulties when implemented on a device with lowstorage capacity. In addition, the complexity of such a scheme isincreased, if the device has to operate correctly with power-failurese.g. an operation must not create a logical inconsistency if power isremoved partway through the operation.

Since the actual number of keys that can be stored in a low storagecapacity QA Device depends on the complexity of the program code and thesize of the data structures, it is useful to minimise the functionalcomplexity and minimise the size of the structures while not knowing thefinal number of keys.

In particular, the scheme must cope with multiple keys having the samepermissions for a field to support the following situations:

each of the various users of the QA Device has access to a differentkey, such that different users can be individually included or excludedfrom accessonly a subset of keys are in use at any one time

The concept that supports this requirement is the keygroup. A keygroupcontains a number of keys, and each field has a set of permissions withrespect to the keygroups. Thus keygroup 1 (containing some number ofkeys) may have read-only permissions on field 1, but read/writepermissions on field 2 and read/decrement-only permissions on field 3.

In the limit case of 1 key per keygroup, with an arbitrary number ofkeygroups, the storage requirements for the permissions on each fieldwould be the same as the general case without keygroups, but by limitingthe number of keygroups, the storage requirements for the permissions oneach field can be pre-known, constant, and is decoupled from the actualnumber of keys in the device.

The number of keygroups in a QA Device is 4. This allows for 2 differentkeygroups that can transfer value into the QA Device, and for 2different keygroups that can transfer value out of a QA Device, whereeach of the 4 keygroups is independent of the others. Note thattransport keys do not need to be allocated a keygroup since they cannotbe used to authorise reads or writes of data.

Thus each keyslot contains a 2-bit KeyGroup identifier. The value ofKeyGroup is relevant only when the KeyType=DataKey.

For security concerns it is important that a field not be created untilall the keys for a keygroup have been created. Otherwise an attacker maybe able to add a known new key to an existing keygroup and therebysubvert the value associated with the field.

However it is not possible to simply not allow the creation of fieldsuntil all of the keys have been created. It may be that two distinctphases of programming occur, with creation of keys and data based oneach phase. For example a stamp franking system may contain value in theform of ink plus a dollar amount. The keys and fields relating to inkmay be injected at one physical location, while the keys and fieldsrelating to dollars may be injected at a separate location some timelater.

It is therefore desirable to have a boolean indicator that indicateswhether a particular keygroup is locked. Once a keygroup is locked, thenno more keys can be added to that keygroup. The boolean indicator isaccessible per keyslot rather than as a single indicator for eachkeygroup in order that someone reading the keyslot information can know:

whether they can add any more keys to a keygroupwhether they can create fields with write-permissions for the keygroup

When a key is replaced, the keygroup for that key can be locked at thesame time. This will cause the QA Device to change the status of allkeys with the same KeyGroup value from keygroup-unlocked tokeygroup-locked, thereby preventing the addition of any more keys in thekeygroup.

However, a single bit representation of this boolean over-complicates4320-based implementations of QA Devices in that it is not possible toset a single bit in shadowed mode on a 4320 device (to change a lockedstatus from unlocked to locked). Instead, the page containing the keywould need to be erased and the key reconstructed, and this would needto take place per key (where the KeyGroup matched).

Therefore each keyslot contains a 4-bit boolean (which should benybble-aligned within the keyslot data structure) referred to asKeyGroupLocked, where 0000 represents that the keygroup to which the keyin the keyslot belongs is unlocked (i.e. more keys can be added to thekeygroup), and non-zero represents that the keygroup to which the key inthe keyslot belongs is locked (i.e. more keys cannot be added to thekeygroup).

It is finally worth noting that a Key Replacement QA Device does notneed to check whether or not there are fields on the target device withwrite permissions related to a particular keygroup. The reason is thatthe target QA Device only allows field creation related to a keygroup ifthe keygroup is locked. Therefore if there was such a field in thetarget device one of the following is true:

the target QA Device is a fake one created by an attacker. If so, and ifthe attacker does not know the original key, then the replaced key willbe of no value. If the attacker does know the original key, then theycan determine the replacement key (since the replacement key isencrypted using the original key for transport) without creating a fakeQA, and can therefore generate fake value as desired.the target QA Device has come under physical attack (it's a real QADevice). If an attacker can do this, it's easier to allow the keyreplacement first, and then create a fake field. This situation cannotever be detected by the Key Replacement QA Device.

In an ideal world (for the owner of a secret key at least), a givensecret key will remain secret forever. However it is prudent to minimisethe loss that could occur should a key be compromised.

This is further complicated in a system where all of the components of asystem are stored at the user site, potentially without directconnection to a central server that could appropriately update allcomponents after a particular time period or if a compromise is known tohave occurred.

To create rolling keys, two QA Devices A and B are required such that Aand B are intended to work together via a conceptual key k. While asingle key could be used for k, it is more secure to limit the lifetimeof any particular key, and to have a plan in place to remove a key fromuse should it be compromised.

Rolling keys are where multiple keys are stored in at least one of A andB such that different keys can be used at different times during thelife of A and B, different instances of A and B at differing manufacturetimes can be programmed with different keys yet still work together, andkeys can be retired from use in A and/or B.

In the simplest example of the problem, suppose A is embedded in aprinter system that works with ink cartridges containing B. If Acontains a single key k for working with B, then k is required for allBs as long as A is deployed. A compromise of k lasts for the lifetime ofA.

A rolling key example system for this example is where A containsmultiple keys k₁, k₂ . . . kn, each with a different KeyId, where eachof these keys has the same permissions on datafields within A (typicallythey will all belong to the same keygroup in A). At initial manufacture,B contains a single key k₁ (that is also present in A). For a given timeperiod k₁ can be used between A and B. At some later time (or if k₁ iscompromised), Bs are manufactured only containing k₂, and new As aremanufactured only containing k₂, k₃ . . . k_(n), k_(n+1). At a latertime, Bs are manufactured only containing k₃ and new As are manufacturedonly containing k₃, k₄ . . . k_(n), k_(n+1), k_(n+2) etc.

Note that if the keys shared by A and B are all common keys, then acompromise of keys from A will compromise all future value in Bs.However if A contains the variant key form and B contains a base form ofeach key, then compromise of keys in A does not permit an attacker toknow future keys in B and the attacker can therefore not create clone Bsuntil a real B is released and the base key is obtained from B. Thismeans that the more variant keys that can be injected into A the morechanges in B can be coped with out any loss of security.

In the example above, note that if k₁ is compromised, an attacker canstill manufacture clone Bs that will work on older As. It is thereforedesirable to somehow invalidate k₁ on older As at some point to reducethe impact of clone Bs. However it is not usually the case that animmediate cut-off point can be introduced. For example, once Bs arebeing manufactured with k₂, existing Bs containing k₁ may still be inuse and are still valid. Just because k₂ is used with A doesn't meanthat k₁ should be invalidated in A immediately. Otherwise a valid usercould not then use an older valid B in A after using a newer B in A.Likewise, new As typically need to be able to work with valid old Bs.Our example assumes that newer As won't work with older Bs.

Therefore if overlapping timing is required, then several valid keys inuse at a time instead of having only a single valid key in use at atime. Once valid Bs are known to be out of circulation (e.g. due to anexpiry date associated with a B) then a key can be officially retiredfrom being included in the manufacture of new As, and can be invalidatedin old As. The more keys that can be used, the finer-grained theresolution of timing for invalidating a particular key, and hence thegreater the reduction in exposure.

For example, B may be an ink cartridge that has a use-by date of 12months while A is a printer that must last for 5 years:

-   -   If A contains 5 keys, B is issued with a new key each year, and        a new A is released each year, then k₁ will be in B during        year1, k₂ will be in B during year2 etc. As produced in year 2        will need to contain k₁ since old Bs from the previous year are        still valid. Only in year 3 can As be manufactured without k₁,        and old As can have their k₁ invalidated. Clone Bs can therefore        be manufactured by an attacker causing loss during year 1 and 2.        After year 2, those clone Bs won't work on new As, but will        continue to work on old As until k₁ has been invalidated on the        old As.    -   If A contains 10 keys, B is issued with a new key every 6        months, and a new A is released every 6 months, then k₁ will be        in B during the first 6 months, k₂ will be in B during the        second six months etc. As produced in the second and third        6-months will need to contain k₁ since old Bs from the previous        year are still valid. Only in the fourth 6-month can As be        manufactured without k1, and old As can have their k₁        invalidated. Clone Bs can therefore be manufactured by an        attacker causing loss during year 1 and the first half of year        2. After this time, those clone Bs won't work on new As, but        will continue to work on old As until k₁ has been invalidated on        the old As. Thus the addition of keys in A and the changing of        keys at a faster rate (every 6 months compared to every year)        has reduced the exposure of a compromised key without increasing        any risk due to exposure of keys in A.

Of course if A is used with B and a B-like entity called C, then A canhave 1 set of rolling keys with B, and can have a different set ofrolling keys with C. This requires 1 key in B, 1 key in C, and two setsof multiple keys in A.

The rolling key structure can be extended to work with value hierarchy.Suppose A uses value from B, and value in B is replenished by C, then Aand B can have one set of rolling keys, and B and C can have a differentset of rolling keys and each set of rolling keys can roll at differenttimes and rates. In this example:

-   -   A contains multiple variants for use with B    -   B contains 1 base key for use with A, and multiple variants for        use with C    -   C contains 1 base key for use with B    -   A compromise of key(s) in a A does not allow an attacker to        manufacture clone Bs    -   A compromise of key(s) in B does not allow an attacker to        manufacture clone Cs    -   A compromise of the keys in A allows free B resources on that        particular A only—no other As are affected    -   A compromise of the base key in B has a limited exposure of        effect—free B resources are available to attackers for a limited        time, and with each new release of A and C, the amount of        exposure is reduced.    -   A compromise of the base key in C has a limited exposure of        effect—free C resources are available to attackers for a limited        time, and with each new release of B the amount of exposure is        reduced.

In the general case, each of the keys in a set of rolling keys hasexactly the same purpose as the others in the set, and is used in thesame way in the same QA Devices, but at different times in a product'slife span. Each of the keys has a different KeyId. Typically when a setof rolling keys is held in a QA Device, they all belong to the samekeygroup.

When the variant/base form of rolling keys is used, at any given time,only one base key is injected during manufacture. This is the currentmanufactured instance of the rolling key. Several of the key instancescan be used in manufacture, in their variant forms. One by one, thecurrent manufactured instance of the rolling key is replaced bysubsequent instances of the rolling key.

After a period, or after the discovery of a key compromise, a particularcurrent manufactured instance of a key is replaced by the next instancein the rolling key set in all of the QA Devices where it is used.

A set of rolling keys has the following characteristics:

-   -   The number of instances in the set of rolling keys, N. The        rolling key instances are from 0 to N−1.    -   The current manufactured instance of the rolling key. This is        the rolling key instance which is currently being inserted into        manufactured products, in base form. The current manufactured        instance is rolled to the next instance when a suitable length        of time has elapsed, or there is the discovery of a key        compromise.    -   The first and last valid instances of the rolling key set. There        is likely to be a number of valid key instances either side of        the current manufactured instance at any given time.

Rolling key instances which are before the first valid instance areconsidered to be invalid, and they should be invalidated in anymanufactured product in the field whenever they are found. The questionis how to enforce the eradication process, especially if the QA Devicesare not in direct contact with a central authority of some kind.

The QA Logical Interface allows a particular key in a keyslot to beinvalidated. An external entity needs to know which keys are invalid(for example by knowing the invalid keys' KeyIds). Assuming that theentity can read the KeyIds present in a QA Device the entity caninvalidate the appropriate keys in the QA Device. The entity couldrefuse to operate on a QA Device until the appropriate keys have beeninvalidated.

For example, suppose a printer system has an ink cartridge and a refillcartridge. The printer system uses rolling key set 1 to communicate withthe ink cartridge, and the ink cartridge is refilled from the refillcartridge via rolling key set 2. Whenever a refill cartridge is attachedto the system, the refill cartridge contains a specific field containingan invalid key list. The system software in the printer knows that thisfield contains an invalid key list, and refuses to transfer the inkvalue from the refill cartridge to the ink cartridge until it hasinvalidated the appropriate keys on the ink cartridge. Alternatively,every time the system software for the printer is delivered/updated tothe printer (e.g. downloaded off the internet), it can contain a list ofknown invalid keys and can apply these to anything it is connected to,including ink cartridges and refill cartridges. Likewise, if value isinjected into a QA Device over the internet, the value server caninvalidate the appropriate keys on the QA Device before injection ofvalue. Done correctly, the invalid keys will be deleted from use in allvalid systems, thereby reducing the effect of a clone product.

The methods just discussed do not apply if a user exclusively uses fakeQA Devices, and never comes into contact with valid QA Devices that havelists of invalid keys. However it is possible that a system caninvalidate a key by itself after a particular amount of time, but thisrequires the system to know the current time, and the time periodbetween invalidating keys. While this provides the feature required, itshould not be possible under normal circumstances for a user to lieabout the time or to accidentally have the time set to an incorrect one.For example, suppose a user accidentally sets a clock on their computerto the wrong year in the future, the printer attached to the computershould not suddenly invalidate all of the keys for the next 12 months.Likewise, if the user changes the clock back to the previous year,previously invalid keys should not suddenly become valid. This impliesthe system needs to know a Most Recent Validated Date i.e. a date/timethat is completely trustworthy.

If system is in a trusted environment and has an appropriate timekeeping mechanism, then MostRecentValidatedDate can be obtained locally.Otherwise the MostRecentValidatedDate can only be obtained when thesystem comes into contact with another trusted component. The trustedcomponent could be software that runs on system, with a particular builddate (and this date is therefore trusted), or a date stored on a QADevice (providing the date is read from the QA Device via keys and canonly be set by a trusted source).

It is therefore convenient that at least one of the QA Devices insystems that support rolling keys should define at least two fields forthe purposes of key invalidation: a field that contains the invalid keylist (a list of invalid keyIds), and a field that contains a date thatcan contribute to a MostRecentValidatedDate. The Logical QA Interfacecurrently supports a field type specifically for the former (seeAppendix B), while the latter depends on the specifics of a particularapplication.

When allocating KeyIds in a system, it may be convenient to be able totell if two keys are in the same set of rolling keys simply from basedon their KeyIds (therefore independent of instantiation in a keygroup).One way of doing this is to compose the KeyId as 2 parts:

-   -   the RollingKeySetId, which would be unique for a given purpose        within a QA Device infrastructure    -   the RollingKeyInstance, which specifies the keys within the        rolling key set

So, for example, if the 18-bit KeyId could be composed of a 10-bitRollingKeySetId, and an 8-bit RollingKeyInstance. Thus each set ofrolling keys would have 256 unique key values to be used in thesequence.

Suppose we have a configuration that consists of a system A thatcommunicates with a QA Device B. For example, a printer system thatcommunicates with an Operating Parameter QA Device (e.g. containing theprint speed). The system reads the print speed before printing a page.

The only way that A and B can securely communicate is if A and B share akey.

If B has physical security since it is a QA Device, and A does not havesuch high security, then it is desirable to store the variant form ofthe key in A and the base form of the key in B. If the key is extractedfrom A (having less security than B), then at least other systems cannotbe subverted with clone Bs.

However there is the question of injecting the variant key into A. If Acan be programmed with a variant key after B has been attached (e.g. Acontains non-volatile memory), then this is desirable. If A cannot beprogrammed after B has been attached (such as is the case with the SoPECASIC) then A must be programmed with a random number and afterattachment to A, the random number must be transported into B.

A can now create a Trusted QA Device and communicate with B using A'svariant key.

However if A requires to communicate with additional components such asC and D which are not connected to A or B during initial manufacture,there is a requirement to allow the communication but additionallyminimise loss due to key compromise, especially since A is known to beless secure than QA Devices B, C and D. Examples of C and D include aConsumable QA Device such as an ink cartridge, and a Parameter UpgraderQA Device such as a permanent speed-upgrade dongle.

If the base key that is used in B is also used in C and D, then A cancommunicate securely with C and D. The risk of loss from a keycompromise is higher since C and D share the same key.

If A can hold many keys, i.e. can be programmed with many keys duringmanufacture, then A can be programmed with appropriate variant keys forC and D using the same scheme as described above for B.

However, if the cost of injecting multiple keys into A is high (forexample SoPEC has very little non-volatile memory), then an alternativeis required that only uses a single key stored in A. There are twoapproaches to secure communication in this case: communication via keytransport, and communication via signature translation.

The protocol for communicating with a QA Device is now described.Although the implementation of a QA Device varies, with oneimplementation having different capabilities from another, the sameinterface applies to all.

QA Devices are passive: commands are issued to them by the System, whichis an entity mediating the communications between the QA Devices.

There are up to three QA Devices that are relevant to each command:

-   -   The Commanded QA Device, i.e. the QA Device receiving the        command. This QA Device checks any incoming signature (if        present), performs the command, and generates the output        parameters and any outgoing signature as required.    -   The Incoming Signature QA Device, that generated the incoming        signature (if it is present). This is usually a QA Device that        produces and signs the input for the command as its output, but        it might be a Translation QA Device.    -   The Outgoing Signature QA Device, that checks the outgoing        signature (if it is present). This is usually a QA Device that        accepts as input the output of the command, but it might be a        Translation QA Device.

The QA Device Protocol lists a set of commands that can be sent to a QADevice, and for each command, there is a set of valid responses. Theprotocol defines the features that are common to the commands.

A command consists of a number of 32-bit words where the first byte ofthe first word contains a command byte, and subsequent words contain upto four of the following blocks of data:

-   -   An UnsignedInputParameterBlock. This is a set of input        parameters with no accompanying signature.    -   An InputSignatureCheckingBlock. This is a block of data that        tells the QA Device how to check if the        SignedInputParameterBlock is correctly signed. It includes the        signature, and information about how it was constructed.    -   A SignedInputParameterBlock. This is a set of input parameters.        It is often a list of entities, or entity descriptors. The        signature in the InputSignatureCheckingBlock is over this block        and the generator's and checker's nonces. A        SignedInputParameterBlock has a QA Device's ChipId as its first        element. If the SignedInputParameterBlock is list of entities        with the modify bit set, then the ChipId must be the identifier        of the chip being addressed (this ensures that a signed block        for one QA Device cannot be applied to another)    -   An OutputSignatureGenerationBlock. This is a block of data that        tells the QA Device how to generate a signature on the outgoing        data.

The response to a command consists of a number of 32-bit words, wherethe first byte of the first word contains a response byte, andsubsequent words contain up to two of the following blocks of data:

-   -   An OutputParameterBlock. This is often a list of entities. It        may or may not be signed. If it is signed, it has a QA Device's        ChipId as its first element. If the OutputParameterBlock is list        of entities with the modify bit clear, then the ChipId must be        the identifier of the chip responding to the command.    -   An OutputSignatureCheckingBlock. This is present if the        OutputParameterBlock is signed. The signature is generated        according to the OutputSignatureGenerationBlock.

The arrangement of data within each 32-bit word is arranged inbig-endian format. The assumption is that the System and the QA Deviceare processing the commands and responses in big-endian format.

All of the blocks in both command and response are length-tagged: thefirst 32-bit word contains a two-byte length that indicates the blocklength in 32-bit words, followed by the block data itself. The length isinclusive. Thus the length for a parameter block with no data content is1.

The QA Device identifier ChipId is present in allSignedInputParameterBlock and signed OutputParameterBlock entity lists.This ensures that a signature over the block of data uniquely identifiesthe QA Device that the list is for or came from. This prevents attackswhere commands that are intended for one QA Device are redirected toanother, or when responses from one QA Device are passed off as beingfrom another.

If the list is an incoming modify-entity list or an outgoing read-entitylist, then the list ChipId must be the ChipId of the Commanded QADevice. If it is not, then the command fails.

If the list is an incoming read-entity list or an outgoing modify-entitylist, then the list ChipId is typically the ChipId of some other QADevice.

A signed outgoing list of entities being read from a QA Device has asignature over a block of data that includes that QA Device's ChipId.Thus ensures that the data cannot be mistaken for data from another QADevice.

Similarly, a signed incoming list of entities being written to a QADevice has a signature over a block of data that includes that QADevice's ChipId. This ensures that the data cannot be wrongly applied toany other QA Device.

In the operation of some commands, a Commanded QA Device accepts asigned Entity List as input, where the Entity List was generated byanother QA Device A, and produces a signed Entity List as output wherethe output is suitable to be subsequently applied to A as an incomingEntity List. These commands include: Get Key, Transfer Delta, TransferAssign, and Start Rollback.

Commands in the QA Device command set are distinguished by CommandByte.

Table 1 describes the CommandByte values:

Values and Interpretation for CommandByte CommandByte Value DescriptionGET INFO 1 Get summary of information from the QA Device GET 2 Get anonce from the QA Device. CHALLENGE LOCK KEY 3 Lock a specified set ofkeygroups. This GROUPS prevents any keys in the keygroups from beingsubsequently replaced. LOCK FIELD 4 Lock all field creation in the QADevice. CREATION Locking field creation prevents any fields fromsubsequently being created. READ 5 Read a group of key descriptors,field descriptors and/or field values from a QA Device. AUTHENTICATED 6Read a group of key descriptors, field READ descriptors and/or fieldvalues from a QA Device. The results are accompanied by a signature toauthenticate the results. AUTHENTICATED 7 Specify a group of keydescriptors, field READ WITH descriptors and/or field values in a QASIGNATURE Device, and read the signature over that ONLY data. WRITE 8Write a group of field values to fields in the QA Device. AUTHENTICATED9 Write a group of field values to fields in WRITE the QA Device. Thewrite command is authenticated by a signature over the list of fieldvalues. CREATE FIELDS 10 Create a group of fields in a QA Device.REPLACE KEY 11 Replace a key in a QA Device. INVALIDATE 12 Make a key ina QA Device invalid. KEY GETKEY 13 Get an encrypted key from a QADevice. TEST 14 Request a QA Device to test the signature over anarbitrary block of data. SIGN 15 Request a QA Device to create asignature over an arbitrary block of data. TRANSFER 16 Request a QADevice to transfer some value DELTA from it to another QA Device wherethe value is correspondingly reduced in the Commanded QA Device).TRANSFER 17 Request a QA Device to transfer an ASSIGN assignment ofvalue to another QA Device.. START 18 Request a QA Device to beginrollback ROLLBACK proceedings to ensure that a previously transferredvalue has not and can never be used. ROLLBACK 19 Request a QA Device toundo a previously requested transfer of value to another QA Device.

The ResultFlag is a byte that indicates the return status from afunction. Callers can use the value of ResultFlag to determine whether acall to a function succeeded or failed, and if the call failed, thespecific error condition.

Table 2 describes the ResultFlag values and the mnemonics used in thepseudocode

ResultFlag value description Mnemonic Value Description Pass 0 Functioncompleted successfully. Function successfully completed requested task.Fail 1 General failure. An error occurred during function processing. QA2 QA Device is not contactable NotPresent Invalid 3 The QA Device doesnot support the command Command Bad Signature 4 Signature mismatch. Theinput signature didn't match the generated signature. Invalid Key 5Invalid keyslot number. The keyslot specified is greater than the numberof keyslots supported in the QA Device, or the key in the specifiedkeyslot is invalid. Invalid Key 6 The key in the requested keyslot isthe wrong type Type for the particular operation. For example, aTransportKey was requested for a data-based signature, or a DataKey wasrequested for a key- based signature. Key Number 7 A key was specifiedfor a signature which had a Out Of Range key slot number out of rangeKey Not 8 A command was received, authenticated by an Locked unlockedkey. Unlocked keys may not be used to authenticate any operations, withthe exception of the transport of keys, to authenticate and encrypt newkey values. Signature 9 A OutputSignatureGenerationBlock was notGeneration received in a command which requires an Block Absent outgoingsignature Signature 10 A OutputSignatureGenerationBlock was receivedGeneration in a command which does not require an outgoing Blocksignature Wrongly Present Signature 11 A InputSignatureCheckingBlock wasnot received Block Absent in a command which requires an incomingsignature Signature 12 A InputSignatureCheckingBlock was received inBlock a command which does not require an incoming Wrongly signaturePresent Parameter 13 An Input Parameter Block wasn't received in a BlockAbsent command which requires that block, or an Output Parameter Blockwas not generated by a command which requires one. Parameter 14 An InputParameter Block was received in a Block command which does not requirethat block, or an Wrongly Output Parameter Block was generated in aPresent command that does not require one. Too Many 15 The InputParameter Block of the command has a Entities list of more entities thanthe QA Device supports Too Few 16 An Entity List or an Entity DescriptorList was Entities received in a command or sent in a response with noentities. Illegal Field 17 Field Number incorrect. The field numberNumber specified in an entity descriptor does not exist. Illegal Entity18 An entity descriptor in an input or output Descriptor parameter blocklist was set wrongly: it was Modify Bit “modify” when it needed to be“read”, or “read” when it needed to be “modify”. Wrong ChipId 19 The QADevice was given a command which had a SignedInputParameterBlock withmodify- entities, or generated a signed OutputParameterBlock withread-entities, and the ChipId in the signed block was incorrect, i.e.not the ChipId of the QA Device. Illegal Entity 20 An entity in an InputParameter Block of a command was received that is not legal for thatcommand. No Shared 21 An operation was requested in a command to a KeyQA Device which requires a key to be shared between it and another QADevice. If there is no shared key, this error is returned. Invalid Write22 Permission not adequate to perform operation. For Permission example,trying to perform a Write or WriteAuth with incorrect permissions. FieldIs Read 23 A Write or an Authenticated Write command was Only applied toa read-only field that had already been written once. Only 24 A Write oran Authenticated Write command was Decrements applied to adecrement-only field, which was Allowed not a decrement. Key Already 25Key already locked. A key cannot be replaced Locked if it has alreadybeen locked. Illegal Key 26 An Entity Descriptor in an Entity Listwrongly Entity specified a key value or descriptor that is not a legalentity for that command. Illegal Field 27 An Entity Descriptor in anEntity List wrongly Entity specified a field value or descriptor that isnot a legal entity for that command. Key Not 28 A Replace Key commandwas received that was Unlocked attempting to change a locked key. FieldCreation 29 Field creation was attempted in this QA Device, Not Allowedafter it has been locked or there was an attempt to lock field creationafter it had been already locked. Field Storage 30 The QA Device is outof storage space for new Overflow fields. Type 31 Type of the data fromwhich the amount is being Mismatch transferred in the Upgrading QADevice, doesn't match the Type of data to which the amount in beingtransferred in the Device being upgraded. Transfer Dest 32 A transferwas attempted on a field which is not Field Invalid capable ofsupporting a transfer. Rollback 33 The rollback enable field for the QADevice being Enable Field transferred to is invalid. Invalid No Transfer34 There is no transfer source field available to do Source Field thetransfer from. Transfer 35 The transfer source field doesn't have theamount Source Field required for the transfer. Amount InsufficientInvalid 36 One of the command operands was invalid. Operand Field Over37 A Write or an Authenticated Write command was Maximum applied to afield which would have made the Allowed field value exceed the limitimplied by its “maximum allowed” bit field. Transfer Fields 38 The “whoI am” and “who I accept” fields in the Incompatible transfer source andtransfer destination fields are not compatible. Transfer 39 A transferwas attempted which failed. The Rolled Back transfer was successfullyrolled back, so the source and transfer fields are unchanged. NoMatching 40 A Rollback was attempted on a QA Device which Previous hadno record of having done a corresponding Transfer transfer (loss ofprevious record may occur depending on the depth of the rollback cacheKey Not For 41 An operation was requested using a data key for Local Usewhich local use is not permitted.

Users of QA Devices must call the GetInfo function on each QA Devicebefore calling any other functions on that device.

The GetInfo function tells the caller what kind of QA Device this is,what functions are available and what properties this QA Device has. Thecaller can use this information to correctly call functions withappropriately formatted parameters.

The first value returned, QA Device type, effectively identifies whatkind of QA Device this is, and therefore what functions are available tocallers. Source code control identifier tells the caller which softwareversion the QA Device has. There must be a unique mapping of the sourcecode control identifier to a body of source code, under source codecontrol, in any released QA Device.

Additional information may be returned depending on the type of QADevice. The additional data fields of the output hold this additionalinformation.

Table 3 describes each of the output parameters.

Description of output parameters for GetInfo function Parameter #bytesDescription ResultFlag 1 Indicates whether the function completedsuccessfully or not. If it did not complete successfully, the reason forthe failure is returned here. QA Device type 1 This defines the functionset that is available on this QA Device. Source Code 4 This uniquelydefines the source code Control for the QA Device, as controlled by aIdentifier source code control system. Key 1 Bit mask of keygroups whichare not Replacement locked. Key replacement is allowed to Allowed addkeys to those keysgroups. Maximum 1 The number of keyslots the QA Devicenumber of keys can support Number of keys 1 The number of keyslots theQA Device is used currently using Number of key 1 The number ofkeygroups that the QA groups Device is currently using Field creation 1Non-zero if field creation is allowed allowed Number of fields 1 Thenumber of fields which are present in the QA Device Number of read- 2The number of write-once then read-only only words in (ROS) words thatthe QA Device supports device Number of read- 2 The number of write-oncethen read-only only words used (ROS) words that the QA Device iscurrently using Number of 2 The number of writeable (RWS) wordswriteable words that the QA Device supports in device Number of 2 Thenumber of writeable (RWS) words writeable words that the QA Device iscurrently using used ChipId 8 This QA Device's ChipId VarDataLen 1Length of bytes to follow. VarData (VarDataLen This is additionalapplication specific bytes) data, and is of length VarDataLen (i.e. maybe 0).

Table 4 shows the mapping of QA Device Type:

QA Device Types QADevice Type\ Description 1 Base QA Device 2 ValueUpgrader QA Device 3 Parameter Upgrader QA Device 4 Key Replacement QADevice 5 Trusted QA Device

Table 5 shows the mapping between the QA Device type and the availabledevice functions on that QA Device.

Mapping between QA Device Type and available device functions Supportedon QA Device QA Device Function Types Device description Get Info allBase QA Device Get Challenge Lock Key Groups Lock Field CreationAuthenticated Read Authenticated Write Non-authenticated Write CreateFields Replace Key Invalidate Key Transfer Delta 2 Value Upgrader QADevice Start Rollback (e.g. Ink Refill QA Device) Roll Back AmountTransfer Amount 3 Parameter Upgrader QA Device Start Rollback (e.g.Local Upgrader QA Rollback Field Device) GetKey 4 Key Replacement QADevice Sign 5 Trusted Device Test

Table 6 shows the VarData components for Value Upgrader and ParameterUpgrader QA Devices.

VarData for Value and Parameter Upgrader QA Devices VarData LengthComponents in bytes Description DepthOfRollBack 1 The number of datasets that can be Cache accommodated in the Xfer Entry cache of thedevice.

An Authenticated Transfer is the process where a store of value issecurely transferred from one QA Device to another.

A Rollback is where a previous attempted transfer is annulled, when thetransferring QA Device is given evidence that the transfer neversucceeded, and can never succeed in the future.

When a transfer is taking place from one QA Device to another, the QADevice from which the value is being transferred is called the Source QADevice, and the QA Device to which the value is being transferred iscalled the Destination QA Device.

The stores of values can be either consumables, or properties.

In a printing application, consumables are things like picolitres ofink, millimetres of paper, page impressions etc. They are things thatare consumed as the printing process is taking place.

In a printing application, properties are things like printer features,such as the right to print at a certain number of pages per second, orthe right to interwork with a certain bit of equipment, such as a largerink cartridge, (which may be cheaper to buy per litre of ink).

A property can also be a printer licence, which has an implied printerfeature set. That is, if a printer has a licence, it has a certainfeature set, and other non-selectable printer features have certaindefault values.

Properties are things which are not consumed as the printing takesplace, but which can be assigned to a printer and which remain asattributes of that printer.

Fields in QA Devices have a transfer mode, which can be one of:

-   -   Quantity of Consumables: the field represents a volume of        consumables. It can be the destination of a transfer, and if it        has T×DE enabled, then it can be the source of a transfer of        consumables,    -   Single Property: this field represents a single property of a        printer, such as a printer feature or a licence. This field can        be assigned to, as the destination of a transfer, but cannot be        the source of a transfer. Once a property has been assigned, it        becomes operative, and it cannot be transferred any more.    -   Quantity of Properties: this field represents a quantity of        properties, which are in transit to their final destination. It        can be the destination of a transfer, and also the source of a        transfer. A quantity of properties does not confer any property        to the QA Device which has them: they are in transit to the        place where they can be used as properties.    -   Other: this field cannot have value transferred from or to it.

In general, the flow of virtual consumables is from QACO, via the OEMfactories, to the consumable containers, such as ink cartridges in thehome or office. The virtual consumables are created ex nihil in QACO,transferred without being created or destroyed to the home or office,and then consumed. When virtual consumables are assigned to a consumablecontainer to be used in SOHO, it should be done in tandem withphysically filling the container, so that the two are in agreement.

In general, the flow of properties is from QACO, via the OEM factoriesor OEM internet resellers, to printers and dongles, for use in the homeand office. The properties are stored as quantities of properties untilthey get to their final destination, where they are assigned as singleproperties.

There are three general kinds of transfers, each with theircorresponding rollbacks:

-   -   The transfer of a quantity of consumables. This is where a        volume of consumables is transferred from source to destination.        The transfer source field is decreased by the transfer delta        amount, and the transfer destination field is increased by the        same amount. This is a transfer delta.    -   The transfer of a quantity of properties. This is where a        quantity of properties is transferred from source to        destination. The transfer source field is decreased by the        transfer delta amount, and the transfer destination field is        increased by the same amount. This is also a transfer delta.    -   The assignment of a single property. This is where a single        property is transferred from source to destination. The transfer        source field is decreased by 1, and the transfer destination        field is assigned with the property value. This is also a        transfer assignment.

The transfer process has two basic requirements:

-   -   The transfer can only be performed if the transfer request is        valid. The validity of the transfer request must be completely        checked by the Source QA Device before it produces the required        output for the transfer. It must not be possible to apply the        transfer output to the Destination QA Device if the Source QA        Device has already been rolled back for that particular        transfer.    -   A process of rollback is available if the transfer was not        received by the Destination QA Device. A rollback is performed        only if the rollback request is valid. The validity of the        rollback request must be completely checked by the Source QA        Device, before it adjusts its value to a previous value before        the transfer request was issued. It must not be possible to        rollback an Source QA Device for a transfer which has already        been applied to the Destination QA Device i.e the Source QA        Device must only be rolled back for transfers that have actually        failed. Similarly, it must not be possible to apply a transfer        to the Destination QA Device after the rollback has been        applied.

The transfer and rollback process is shown in FIG. 28.

The steps shown in FIG. 28 for a transfer and rollback process are:

-   -   The System performs an Authenticated Read of fields and keys in        the destination QA Device. The output from the read includes        field data, field descriptors, and the key descriptor of the key        being used to authenticate the transfer, and a signature. It is        essential that the fields are read together. This ensures that        the fields are correct, and have not been modified, or        substituted from another device.    -   The System requests a Transfer from the Source QA Device with        the amount that must be transferred, the field in the Source QA        Device the amount must be transferred from, and the field in        Destination QA Device the amount must be transferred to. The        Transfer also includes the output from (1). The Source QA Device        validates the Transfer based on the Authenticated Read output,        checks that it has enough value for a successful transfer, and        then produces the necessary transfer output. The transfer output        typically consists of new field data for the field being        refilled or upgraded, additional field data required to ensure        the correctness of the transfer/rollback, along with a        signature.    -   The System then applies the transfer output to the Destination        QA Device, by calling an Authenticated Write function on it,        passing in the transfer output from (2). The Write is either        successful or not. If the Write is not successful, then the        System may repeat calling the Write function using the same        transfer output, which may be successful or not. If        unsuccessful, the System initiates a Rollback of the transfer.        The Rollback must be performed on the Source QA Device, so that        it can adjust its value to a previous value before the current        Transfer was initiated. It is not necessary to perform a        rollback immediately after a failed Transfer. The Destination QA        Device can still be used.    -   The System starts a Rollback by reading the fields and keys of        the Destination QA Device.    -   The System makes a Start RollBack request to the Source QA        Device with same input parameters as the Transfer, and the        output from Read in (4). The Source QA Device validates the        Start RollBack Request based on the Read output, and then        produces the necessary Start Rollback output. The Start Rollback        output consists only of additional field data along with a        signature.    -   The System then applies the Start Rollback output to the        Destination QA Device, by calling an Authenticated Write        function on it, passing in the Start Rollback output.    -   The Write is either successful or not. If the Write is not        successful, then either (6), or (5) and (6) must be repeated.    -   The System then does an Authenticated Read of the fields of the        Destination QA Device.    -   The System makes a RollBack request to the Source QA Device with        same input parameters as the Transfer request, and the output        from Read (7). The Source QA Device validates the RollBack        request based on the Authenticated Read output, and then rolls        back its field corresponding to the transfer.

There are two fields in every QA Device which can be the destination ofa transfer, called the rollback enable fields.

The rollback enable fields are called RollbackEnable1 andRollbackEnable2 with field types=TYPE_ROLLBACK_ENABLE_1 andTYPE_ROLLBACK_ENABLE_2 respectively (see Table 329). They each have atransfer mode of “other”, which means that they are never thedestination field of a transfer, that is, they never get valuetransferred to them. However, they take part in the authenticated writeswhich transfer value to other fields.

Both rollback enable fields are decrement-only fields, initialised to0×FFFFFFFF when they are created, and they can only be decreased viaauthenticated writes.

When a transfer is requested, the authenticated read contains the fielddescriptors and field values for the rollback enable fields. Thetransfer source QA Device checks that they are present, and rememberstheir values.

The authenticated write for the transfer includes:

-   -   An assignment to the destination field being updated,    -   A decrement of −1 to RollbackEnable1, and    -   A decrement of −2 to RollbackEnable2.

If a rollback is requested, then the transfer source QA Device generatesthe arguments for an authenticated write to the transfer destinationwhich include:

-   -   A decrement of −2 to RollbackEnable1, and    -   A decrement of −1 to RollbackEnable2.

This authenticated write only works if the transfer write had never beenapplied, (because otherwise the rollback write would be incrementingRollbackEnable2, which is not allowed; it is a decrement-only field.)

The pattern of “rollback enable value −1” and “rollback enable value −2”means that only one of the authenticated writes can be applied, notboth. If the Transfer write has succeeded, then the Rollback write cannever be applied, and if the Rollback write has succeeded, then theTransfer write can never be applied.

If the rollback write is successfully applied to the transferdestination, then another Authenticated Read is made to the rollbackenable fields. This is presented as evidence to the transfer source QADevice, and if it can see that the rollback write has been successfullyapplied, it rolls back the transfer, and increments its source field.

The basic authorisation for a transfer comes from a key that hasauthenticated ReadWrite permission (stored in field information asKeyNum) to the destination fields in the Destination QA Device. This keyis referred to as the transfer key.

After validating the input transfer request, the Source QA Devicedecrements the amount to be transferred from its source field, andproduces the arguments for an authenticated write, and a signature usingthe transfer key.

The signature produced by the Source QA Device is subsequently appliedto the Destination QA Device. The Destination QA Device accepts thetransfer amount only if the signature is valid. Note that the signatureis only valid if it was produced using the transfer key which has writepermission to the destination field being written.

The Source QA Device validates the transfer request by matching the Typeof the data in the destination field of Destination QA Device to theType of data in the source field of the Source QA Device. This ensuresthat equivalent data Types are transferred e.g. a quantity of typeNetwork_OEM1_infrared ink is not transferred into a field of typeNetwork_OEM1_cyan ink.

Each field which may be transferred from or to has a compatibility wordin its field descriptor. The compatibility word consists of two 16-bitfields, called “who I am” and “who I accept”. For the transfer to takeplace, each side must accept the other. That is expressed in this way:if (the source “who I am” bitwise-ANDed with the destination “who Iaccept” is non-zero) AND (the destination “who I am” bitwise-ANDed withthe source “who I accept” is non-zero) are both non-zero, then thetransfer can take place, otherwise it can't.

In addition, when a quantity of properties is being transferred, thesource field's “upgrade to/from” word is used as follows:

-   -   If the assignment is a “transfer delta”, then the “upgrade        to/from” words in the source and destination fields must match,        and    -   The transfer is a “transfer assignment”, then the previous value        of the property must have been the “upgrade from” value, and        then the assignment is of the “upgrade to” value.

This is the complete list of checks that must be made by the transfersource QA Device, before a transfer is authorised.

-   -   The signature for the authenticated read matches    -   The keygroup for the incoming data is locked, and the key is        valid, is of type DataKey, and has a UseLocally set to 1.    -   All of the incoming fields can be written or at least        decremented by the incoming key.    -   The transfer source QA Device has the appropriate key for the        transfer    -   The rollback enable fields are present    -   The rollback enable field descriptors are decrement-only,        type=rollback enable, transfer mode=other    -   The rollback enable values are >=2    -   Source and destination field types match    -   Source and destination compatibility fields are compatible    -   If the transfer operation is “transfer delta”, then        -   Destination volume+delta<=maximum allowed at destination        -   Source volume >=delta        -   The source and destination fields either both have or both            do not have an “upgrade option from/to” value        -   If the source field has an “upgrade option from/to” value,            then it matches the destination field's value        -   The source and destination fields' transfer modes must be            the same, and they must be either “quantity of consumables”            or “quantity of properties”    -   If the transfer operation is “decrement and assign”, then        -   The source field's transfer modes must be “quantity of            properties”, and the destination field's transfer mode must            be “single property”        -   Destination value=“option from” value of the “upgrade option            from/to” value    -   If any of these tests fail, then the transfer cannot proceed.    -   The Authenticated Write arguments should have these values:        -   The RollbackEnable1 field should have an authenticated write            of its previous value −1        -   The RollbackEnable2 field should have an authenticated write            of its previous value −2    -   If the transfer operation is Transfer Delta, then:        -   Destination volume should be set to original volume+delta.    -   If the transfer operation is “decrement and assign”, then    -   Destination value=“option to” value of the “upgrade option        from/to” value    -   The implied delta value is 1.

The arguments of the Authenticated Write should have the “write/add” bitin the entity descriptors set to “add”, for the rollback enables, andthe field value in the Transfer Delta case. It should be set to “write”for the field value in the Transfer Assign case. The use of the “add”option in the Authenticated Write eliminates a class of race conditions.

The Transfer Delta function is to transfer value, the value being aquantity of consumables or a quantity of properties. This distinction(compared to a Transfer Assign) is above.

It produces as its output the data and signature for updating givenfields in a destination QA Device with an Authenticated Write. The dataand signature when applied to the appropriate device through theAuthenticated Write function, updates the fields of the device.

The system calls the Transfer Delta function on the upgrade device witha certain Delta. This Delta is validated by the Transfer Delta functionfor various rules, the function then produces the data and signature forthe passing into the Authenticated Write function for the device beingupgraded.

The Transfer Delta output consists of the new data for the field beingupgraded, field data of the two rollback enable fields, and a signatureusing the transfer key.

The following data is saved in the transfer Source QA Device's RollbackBuffer:

-   -   The field number in the transfer source,    -   The field number in the transfer destination,    -   The key slot number in the transfer source,    -   The key slot number in the transfer destination,    -   The destination ChipId,    -   The destination rollback enable counters, values and        descriptors,    -   The destination key descriptor.    -   The delta.

Non-volatile memory is memory that retains its state after power isremoved. For example, flash memory is a form of non-volatile memory. Theterms flash memory and non-volatile memory are used interchangeably inthe detailed description.

In a flash memory, a bit can either be in its erased state or in itsprogrammed state. These states are referred to as E and P. For aparticular flash memory technology, E may be 0 or 1, and P is theinverse of E.

Depending on the flash technology, a FIB (Focused Ion Beam) can be usedto change chosen bits of flash memory from E to P, or from P to E. Thusa FIB may be used to set a bit from an unknown state to a known state,where the known state depends on the flash memory technology.

An integrated circuit (IC or chip) may be manufactured with flashmemory, and may contain an embedded processor for running applicationprogram code.

XOR is the bitwise exclusive- or function. The symbol is used for XOR inequations.

A Key, referred to as K, is an integer (typically large) that is used todigitally sign messages or encrypt secrets. K is N bits long, and thebits of K are referred to as K₀ to K_(N−1), or K_(i), where i may runfrom 0 to N−1.

The Binary Inverse of a Key is referred to as ˜K. The bits of K arereferred to as ˜K_(i), where i may run from 0 to N−1.

A Random Number used for the purposes of hiding the value of a key whenstored in non-volatile memory is referred to as R. The bits of R arereferred to as R_(i), where i may run from 0 to N−1.

If a function of a key K is stored in non-volatile memory, it isreferred to as X. The bits of X are referred to as X_(i), where i mayrun from 0 to N−1.

In embedded applications, it is often necessary to store a secret key innon-volatile memory such as flash on an integrated circuit (IC), inproducts that are widely distributed.

In certain applications, the same key is stored in multiple ICs, allavailable to an attacker. For example, the IC may be manufactured into aconsumable and the consumable is sold to the mass market.

The problem is to ensure that the secret key remains secret, against avariety of attacks.

This document is concerned with FIB (Focussed Ion Beam) attacks onflash-based memory products. Typically a FIB attack involves changing anumber of bits of flash memory from an unknown state (either E or P)into a known state (E or P). Based on the effect of the change, theattacker can deduce information about the state of the bits of the key.

After an attack, if the chip no longer works, it is disposed of. It isassumed that this is no impediment to the attacker, because the chipsare widely distributed, and the attackers can use as many of them asthey like.

Note that the FIB attack is a write-only attack—the attacker modifiesflash memory and tests for changes of the chip behaviour.

Attacks that involve reading the contents of flash memory are much moredifficult, given the current state of flash memory technology. However,if an attacker were able to read from the flash memory, then it would bestraightforward to read the entire contents, then to disassemble theprogram and calculate what operations are being performed to obtain thekey value. In short, all keys would be compromised if an attacker iscapable of arbitrary reads of flash memory

Note that this document is addressing direct attacks on the keys storedin flash memory. Indirect attacks are also possible. For example, anattacker may modify an instruction code in flash memory so that thecontents of the accumulator are sent out an output port. Indirectattacks are not addressed in this document.

If a key K consisting of N bits is stored directly in non-volatilememory, and an attacker knows both N and the location of where K isstored within the non-volatile memory, then the attacker can use asimple FIB attack to obtain K.

For each bit i in K:

-   -   The attacker uses the FIB to set K_(i) to P,    -   If the chip still works the attacker can deduce that the bit was        originally P.    -   If the chip no longer works, then the attacker can deduce that        the bit was originally E.

A series of FIB attacks allows the attacker to obtain the entire key. Atmost, an attacker requires N chips to obtain all N bits, but on averageonly N/2 chips are required.

If the attacker cannot set a bit to P, but can set it to E, then anequivalent attack is possible. i.e. For each bit i in K:

-   -   The attacker uses the FIB to set K_(i) to E,    -   If the chip still works the attacker can deduce that the bit was        originally E.    -   If the chip no longer works, then the attacker can deduce that        the bit was originally P.

Thus storing a key directly in non-volatile memory is not secure,because it is easy for an attacker to use a FIB to retrieve the key.

Instead of storing K directly in flash, it is possible to store R and X,where R is a random number essentially different on each chip, and X iscalculated as X=K R. Thus K can be reconstructed by the inverseoperation i.e. K=X R.

In this case, a simple FIB attack as described in Section 2.1 will notwork, even if the attacker knows where X and R are stored. This isbecause the bits of X are essentially random, and will differ from onechip to the next. If the attacker can deduce that a bit of X in one chipis a certain state, then this will not have any relation to what thecorresponding bit of X is in any other chip.

Even so, an attacker can still extract the key. For each bit i in thekey:

-   -   The attacker uses the FIB to set both X_(i) and R_(i) to P,    -   If the chip still works, the attacker knows that X_(i) and R_(i)        were originally either both P or both E. Both of these cases        imply that the key bit K_(i) is 0.    -   If the chip no longer works, the attacker knows that exactly one        of X_(i) and R_(i) was originally P and one was E. This implies        that the key bit K_(i) is 1.    -   If the chip no longer works, replace it with a new chip.

If the attacker cannot set a bit to P, but can set it to E, then anequivalent attack is possible.

A series of FIB attacks allows an attacker to obtain the entire key. Foreach bit, there is a 50% chance that the chip cannot be reused becauseit is damaged by the attacks (this is the case where X_(i)< >R_(i)).This means that on average it will take it will take an attacker 50%×Nchips to obtain all N bits.

Therefore this method of storing a key is not considered secure, becauseit is easy for an attacker to use a FIB to retrieve the key.

Instead of storing K directly in flash, it is possible to store K andits binary inverse ˜K in flash such that for each chip, K is storedrandomly in either of 2 locations and ˜K is stored in the other of the 2locations (the program that accesses the key also needs to know theplacement). As a result, given a randomly selected chip, an attackerdoes not know whether the bit stored at a particular location belongs toK or ˜K.

If the program in flash memory checks that the value read from the firstlocation is the binary inverse of the value stored in the secondlocation, before K is used, and the program fails if it is not, then anattacker cannot use the behaviour of the chip to determine whether asingle bit attack hit a bit of K or ˜K.

However the chip is subject to an attacker performing multiple-bit FIBattacks, assuming that the attacker knows the two locations where K and˜K are stored, but does not know which location contains K; and that theprogram in the chip checks that the values stored at the two locationsare inverses of each other, and fails if they are not.

For each bit i>0 in the key:

-   -   The attacker chooses a positive integer T.    -   The attacker repeats the following experiment up to T times, on        a series of chips:        -   The attacker uses the FIB to set bits 0 and i of the value            stored at one of the 2 locations (the attacker doesn't know            if the value is K or ˜K) to P,        -   If the chip still works, then the attacker can deduce that            K₀ and K_(i) have the same value: they are either both 1 or            both 0. This is because the bits that were attacked must            have both been originally P, and the FIB left them that way,            and so the chip still worked. It is not clear whether the            attacked bits were in K or ˜K, and so the attacker can't            deduce whether the key bits were 0 or 1, but the attacker            has discovered that K₀ and K_(i) are the same. If this            result occurs, stop repeating the experiment.        -   If the chip no longer works, then the attacker can only            deduce that either the bits in the key are different, (with            a probability ⅔), or the bits in the key are the same but            the attack hit the bits in the key or the inverse that were            both E, (with a probability of ⅓). That is, the attacker can            get no certain information from this result, but can get a            probable result.            -   3. After T attempts, if there have been any results that                indicate that K₀ and K_(i) have the same value, then the                attacker knows that the bits are the same. Otherwise,                the attacker knows that there is a (⅓)^(T) probability                that the bits are the same. The probability that K₀ and                K_(i) are the same can be made arbitrarily close to 0 by                increasing T until the attacker has an appropriate level                of comfort that the bits are different.

If the attacker cannot set a bit to P, but can set it to E, then anequivalent attack is possible.

At the end of the experiments, the relation of K₀ to all of the otherkey bits K_(i) (i=1 to N−1), is either known or almost certainly known.This means that the key value is almost certainly known to within twoguesses: one where K₀=0, and the other where K₀=1. For each guess, theother key bits K_(i) are implied by the known relations. The attackercan try both combinations, and at worst may need to try othercombinations of keys based on the probabilities returned for each bitposition during the experiment.

An attacker can use a series of FIB attacks to obtain the entire key.For each K_(i), there is a 75% chance that the chip cannot be reusedbecause it is damaged by the attacks: this is the case where the testedbits K₀ and K_(i) were not both P. On average, it will take 1.5 attemptsto determine that K₀ and K_(i) are identical, and T attempts to findthat K₀ and K_(i) are different. This means that on average it will takeit will take an attacker 75%×(T+1.5)/2×(N−1) chips to obtain therelations between K₀ and the other N−1 bits.

Therefore this method of storing a key is not considered secure, becauseit is easy for an attacker to use a FIB to retrieve the key.

It is possible to store X, ˜X and R in flash memory where R is a randomnumber, K is the key, X=K R, and ˜X=˜K R.

X, ˜X and R are stored in memory randomly with respect to each other,and the program that accesses the key also needs to know the placement.Thus, for a randomly selected chip it is not clear to an attackerwhether a bit at a particular location belongs to X, ˜X or R.

It is assumed that the attacker knows where X, ˜X and R are stored, butdoes not know which one is stored in each of the 3 locations; and thatthe program in the chip checks that the stored value for X is indeed thebinary inverse of the stored value for ˜X, and fails if it is not.

An attacker cannot extract the key using the method described in Section2.3 because that method will reveal whether X₀ is the same as X_(i),(where X is one of X, ˜X and R), for an individual chip, but this cangive no information about the relationship of K₀ and K_(i), because theyare XORed with the random R that differs from chip to chip.

So a “pairs of bits” FIB attack cannot get the attacker any informationabout K.

However, K still susceptible to attack, by an attacker performing FIBattacks on pairs of bit pairs.

It is assumed that the chip is programmed with X, ˜X and R, and they arein known locations, but it is not known by the attacker what order theyare in; and that the program in the chip checks that stored value for Xis indeed the binary inverse of the stored value for ˜X, and fails if itis not.

For each bit i>0 in the key:

-   -   Choose a positive integer T.    -   Repeat this experiment up to T times, on a series of chips:        -   The attacker uses the FIB to set bits 0 and i of two of the            entities (X, ˜X or R), to P. The attacker does not know            which of the entities were hit.        -   If the attacker hits bits in X and R, and all 4 of them were            P, or if the attacker hits bits in ˜X and R, and all 4 of            them were P, then the program will always pass. In these            events, the attacker can deduce that K₀ and K_(i) are the            same. The probability of this outcome is ⅙. If this result            occurs, stop repeating the experiment.        -   If the attacker hits bits in X and R, and not all 4 of them            were P, or if the attacker hits bits in ˜X and R, and not            all 4 of them were P, then the program will always fail. In            this case the attacker can only deduce that either the bits            in the key are different, or the bits in the key are the            same but the attack hit the bits in the key or the inverse            that were both E. That is, the attacker can get no certain            information from this result, but can get a probable result.            The probability of this outcome is ½. The probability of            this outcome when K₀=K_(i) is ⅙. The probability of this            outcome when K₀< >K_(i) is ⅓.        -   If the attacker hits bits in X and ˜X, then the program will            always fail, because the corresponding bits in X and ˜X must            be different (by definition). One bit from each bit pair            must have been changed from P to E by the attack, and the            program checks will fail. In this event, the attacker cannot            find out any information about the bits of the key K. The            probability of this outcome is ⅓. The probability of this            outcome when K₀=K_(i) is ⅙. The probability of this outcome            when K₀< >K is ⅙.    -   After T attempts, if there have been any results that indicate        that K₀ and K_(i) have the same value, then the attacker knows        that the bits are the same. Otherwise, the attacker knows that        there is a (⅖)^(T) probability that the bits are the same. The        probability that K₀ and K_(i) are the same can be made        arbitrarily close to 0 by increasing T. That is, the attacker        can be almost certain that the bits are different.

If the attacker cannot set a bit to P, but can set it to E, then anequivalent attack is possible.

At the end of the experiments, the relation of K₀ to all of the otherkey bits K_(i) (i=1 to N−1), is either known or almost certainly known.This means that the key value is almost certainly known to within twoguesses: one where K₀=0, and the other where K₀=1. For each guess, theother key bits K_(i) will be implied by the known relations. Theattacker can try both combinations, and at worst may need to try othercombinations of keys based on the probabilities returned for each keyposition during the experiment.

Thus an attacker can use a series of FIB attacks to obtain the entirekey.

Therefore this method of storing a key is not considered secure becauseit is not difficult for an attacker to use a FIB to retrieve the key.

The above-described attacks rely on the attacker having knowledge ofwhere the key K and related key information are placed within flashmemory.

If the program insertion re-links the program every time a chip isprogrammed, then the key and key-related information can be placed in anarbitrary random places in memory, on a per-chip basis. For any givenchip, the attacker will not know where the key could be.

This will slow but not stop the attacker. It is still possible to launchstatistical attacks to discover the key.

This section shows how any attack that can succeed against keys in knownlocations can be modified to succeed against keys that are placed innon-overlapping random locations, different for every programmed chip.The following assumptions are made:

-   -   That the places where the key information may be stored do not        overlap with each other. That is, if a FIB attack hits a bit of        key information, the attacker knows which bit of the key was        hit, and    -   That the attacker knows the possible locations of the key        information, and their alignment, and    -   That if a FIB attack leaves a chip reporting that the key was        wrong, then it is more likely that this was because the key was        corrupted, than because some part of the program code that        manipulates the key was hit.

When an attacker attacks a bit in flash memory with a FIB attack to setits state to P there are a number of possibilities:

-   -   A bit can be hit that is already in the state P, and is        therefore not changed. There is no change of behaviour of the        chip. In some circumstances this can provide the attacker with        some information.    -   A bit that is part of some key-related information can be hit,        and the bit changes from state E to P. This will cause the        program to fail, reporting an incorrect key value.    -   A bit that is not part of some key-related information can be        hit, and the bit changes from state E to P. This may or may not        cause the chip to fail for some other reason.

There are an equivalent set of possibilities if the attacker uses a FIBattack to set the state of a bit to E.

It is important to distinguish between the two kinds of failures: (a)failures where the program either reports an incorrect key value, or itis clear that the key value is incorrect, because it is unable toencrypt, and (b) other kinds of failures. If the program becomes unableto do key-related functions (encrypt, decrypt, digitally sign or checkdigital signatures, etc), but is otherwise functioning well, then theattacker can deduce that the most recent attack probably hit somekey-related information.

If a program stops working, or comes up with some other unrelated errorcondition, then the most recent attack hit some part of the flash memorythat was not key information, but was necessary for something else.

In the situation where K is placed into a random location in flashmemory for each chip, and that the possible locations for the key cannotoverlap with each other, then an attacker can extract the key.

For each bit i in N−1:

-   -   Choose a positive integer T.    -   Repeat the following experiment T times, on a series of chips:        -   The attacker chooses the address A of a potential key.        -   The attacker uses the FIB to set the A_(i) to P.        -   If the chip gets an error that implies that it has an            incorrect key value, then probably K was actually at            address A. In this case, the attacker records a hit, and            records that K_(i). is probably E.        -   Otherwise the attacker records a miss.        -   The attacker would do well to discard the chip, whether or            not the chip failed. This is because there might be some            silent damage to the chip, that could interact in unexpected            ways with subsequent FIB attacks. It is safer to start each            new experiment with a new chip.

After T attempts, the attacker has a record of how many hits H_(i) wererecorded for bit i in the key.

Since there are N key bits in flash memory, out of a total of M totalbits of flash memory, the attacker can expect that a key bit was hit Nout of M times. Sometimes this hit would have changed a bit from E to P,and other times it would leave the bit unchanged at P.

The attacker is now able to observe that for each bit i, the H_(i)/Tconverge to two values: N/M and 0. If H_(i)/T=N/M, then K_(i). isprobably E, and if H_(i)/T=0, then K_(i). is probably P.

To launch this attack, an attacker requires T×N chips. Note that for theexperiments to be useful, T needs to be large enough to launch an attackon M.

If the attacker cannot set a bit to P, but can set it to E, then anequivalent attack is possible.

This method of storing a key is not considered secure, because it isdifficult, though not impossible, for an attacker to use an FIB toretrieve the key.

In the situation where for each chip, K and ˜K are each placed into arandom location in flash memory such that the possible locations forstorage do not overlap with each other, and that the program in the chipchecks that the stored values at the two locations are inverses of oneanother and fails if it is not, then an attacker can extract the key.

For each bit i in N−1:

Choose a positive integer T.

Repeat this experiment T times, on a series of chips:

-   -   The attacker chooses an address A (hoping it will be the address        of K or ˜K).    -   The attacker uses the FIB to set bits A₀ and A_(i) to P.    -   If the chip gets an error that implies that it has an incorrect        key value, then probably either K or ˜K was actually at        address A. In this case, the attacker records a hit. The        attacker can also deduce that bits A₀ and A_(i) were not both P.        This can mean one of 2 things:        -   A₀ and A_(i) were different, and they were part of K or ˜K.            This implies that K₀< >K_(i). This happens ⅔ of the time.        -   A₀ and A_(i) were both E, and they were part of K or ˜K.            This implies that K₀=K_(i). This happens ⅓ of the time.    -   Otherwise the attacker records a miss.    -   The attacker would do well to discard the chip, whether or not        the chip failed. This is because there might be some silent        damage to the chip, that could interact in unexpected ways with        subsequent FIB attacks. It is safer to start each new experiment        with a new chip.

After T attempts, there will be a record of how many hits H_(i) wererecorded for bit i in the key.

Since there are 2N bits in flash memory containing K and ˜K, out of atotal of M total bits of flash memory, the attacker can expect thatkey-related bits were hit 2N out of M times.

The attacker should observe that for each bit i, the H_(i)/T converge totwo values: N/M and N/2M. If H_(i)/T=N/M, then K_(i) is probably ˜K₀,and if H_(i)/T=N/2M, then K_(i). is probably K₀.

At the end of the experiments, the relation of K₀ to all of the otherkey bits K_(i) (i=1 to N−1), is probably known. This means that the keyvalue is probably known to within two guesses: one where K₀=0, and theother where K₀=1. For each guess, the other key bits K_(i) will beimplied by the known relations. The attacker should try bothcombinations.

To launch this attack, an attacker requires T×N chips. Note that for theexperiments to be useful, T needs to be large enough to launch an attackon M.

If the attacker cannot set a bit to P, but can set it to E, then anequivalent attack is possible.

Therefore this method of storing a key is not considered secure, becausealthough it is difficult, it is not impossible for an attacker to use aFIB to retrieve the key.

Storing a key in arbitrary non-overlapping places in flash memory willslow but not stop a determined attacker.

The same methods of attack that work for keys in known locations, workfor keys in unknown locations. They are slower because they rely onstatistics that are confounded with the failures that occur because ofreasons other than corruption of keys.

A sufficient number of experiments allows the attacker to isolate thefailures caused by differences in the value of the bits of keys fromother failures.

The above-described attacks rely on the attacker having knowledge ofwhere the key K and related key information are placed within flashmemory, or knowledge that the locations where the key information may beplaced do not overlap each other.

It is possible to place the key and key-related information in randomlocations in memory on a per-chip (assuming the program that referencesthe information knows where the information is stored). For a randomlyselected chip, the attacker will not know exactly where the key isstored. This will slow but not stop the attacker. It is still possibleto launch statistical attacks that discover the key.

Any attack that can succeed against keys in known locations can bemodified to succeed against keys that are placed in random locations,different for every programmed chip. The following assumptions are made:

-   -   If a FIB attack leaves a chip reporting that the key was wrong,        then it is more likely that this was because the key was        corrupted, than because some part of the program code that        manipulates the key was hit.

Some inside information is helpful for the attack.

For a given computer architecture and software design, the keys will beheld in memory in units of a particular word size, and those words willbe held in an array of words, aligned with the word size. So, forexample, a particular key might be 512 bits long, and held in an arrayof 32-bit words, and the words are aligned in flash memory at 32-bitboundaries. Similarly, another system might have a key that is 160 bitslong, held in an array of bytes, aligned on byte boundaries.

Additional useful information for the attacker is the minimum alignmentin flash memory for the key, denoted by W.

If a key is N bits long, aligned with a word-size of W, and placed inflash memory starting at an arbitrary word address, then there will beN/W bits that are aliased together from the point of view of theattacker. This is called the aliased bit group. This is because anattack on bit x in flash could be a hit to K_(i), K_(i+W), K_(i+2W),etc, depending on which word in memory the key started.

For example, if a particular key is 512 bits long, and is held in anarray of 32-bit words, then there are 16 elements (512/32) in eachaliased bit group. Similarly, if another system's key is 160 bits long,held in an array of bytes, then there are 20 elements (160/8) in eachaliased bit group.

When an attacker discovers something about a particular chip's key byattacking a bit of flash memory, the attacker can generally only deducesome bulk characteristics of the aliased bit group, rather thanindividual bits of the key. For small enough aliased bit groups,however, this can dramatically reduce the search size necessary tocompromise the key.

The boundary conditions of aliased bit groups allows an attacker togather particular types of statistics:

-   -   If a flash memory stores key related information on arbitrary        bit boundaries, then the word size is 1, and the aliased bit        group size is the key size. In this situation, the attacker can        only gather statistics about the key bits as a whole.    -   If a flash memory stores key related information in words with        an alignment greater than or equal to the key size, then the        aliased bit group size is 1. In this situation, each bit of        flash memory can only be a unique bit of the key, and any        key-related information the attacker finds about that bit of        flash memory can be applied to exactly that key bit.

It is in the attacker's interest for the word size to be as large aspossible, so that there is a minimum of aliasing of bits.

When an attacker attacks a bit in flash memory with a FIB attack, thereare a number of possible outcomes:

-   -   A bit can be hit that is already in the state P, and is        therefore not changed. There is no change of behaviour of the        chip. In some circumstances this can provide the attacker with        some information.    -   A bit that is part of some key-related information can be hit,        and the bit changes from state E to P. This will cause the chip        to become unable to use its key correctly, and the program will        fail.    -   A bit that is not part of some key-related information can be        hit, and the bit changes from state E to P. This may or may not        cause the chip to fail for some other reason.

There are an equivalent set of possible outcomes if the attacker uses aFIB attack to set the state of a bit to E.

It is important to distinguish between the two kinds of failures: (a)failures where the program becomes unable to use its key, and (b) otherkinds of failures. If the program becomes unable to do key-relatedfunctions (encrypt, decrypt, digitally sign or check digital signatures,etc), but is otherwise functioning well, then the attacker can deducethat the most recent attack hit some key-related information.

If a program stops working, or comes up with some other unrelated errorcondition, then the most recent attack hit some part of the flash memorythat was not key information, but was necessary for something else.

If the key K is placed into a random location in flash memory for eachchip, then an attacker can extract the key.

For each bit i in 0−W−1, where W=the word size:

Choose a positive integer T.

The attacker repeat the following experiment T times, on a series ofchips:

-   -   The attacker chooses the address A of a word in flash memory.    -   The attacker uses the FIB to set the A_(i) to P.    -   If the chip becomes unable to use the key K, then clearly the        word at address A was in K. That is, A_(i)=K_(i+jW), where        (i+jW)<N. In this case, the attacker records a hit.    -   Otherwise the attacker records a miss.    -   The attacker would do well to discard the chip, whether or not        the chip failed. This is because there might be some silent        damage to the chip, that could interact in unexpected ways with        subsequent FIB attacks. It is safer to start each new experiment        with a new chip.

After T attempts, there will be a record of how many hits H_(i) wererecorded for bit i in the word size.

At the end of the experiment, the attacker has W fractions H_(i)/T, onefor every bit in the flash memory's words.

Since there are N key bits in flash memory, out of a total of M totalbits of flash memory, the attacker can expect that a key bit was hit Nout of M times. Sometimes this hit would have changed a bit from E to P,and other times it would leave the bit unchanged at P.

If all of the bits in the key's aliased bit group were E, then theattacker should expect that H_(i)/T=N/M. That is, all of the bits of aparticular word bit i that hit a key bit changed it from E to P.

If all of the bits in the key's aliased bit group were P, then theattacker should expect that H_(i)/T=0. That is, all of the bits of aparticular word bit i that hit a key bit left it unchanged at P.

If there are k bits in the aliased bit group, then the attacker shouldbe able to observe that Bi=k(H_(i)/T)/(N/M) takes on k+1 values, from 0to k, for each bit i in the flash memory words.

B_(i) is the number of bits in the aliased bit group that are E in thekey. k−B_(i) is the number of bits in the aliased bit group that are Pin the key. So the attacker knows to within a permutation what the keybit values are.

To launch this attack, an attacker requires T×W chips. Note that for theexperiments to be useful, T needs to be large enough to launch an attackon M.

If the attacker cannot set a bit to P, but can set it to E, then anequivalent attack is possible.

Therefore this method of storing a key is not considered secure, becauseit is difficult, though not impossible, for an attacker to use a FIB toretrieve the key.

If K and ˜K are each placed into one of two random locations in flashmemory for each chip, and the program checks that the stored values inboth locations are binary inverses of each other and fails if they arenot, then an attacker can extract the key.

For each bit i in 1−W−1, where W=the word size:

Choose a positive integer T.

The attacker repeat the following experiment T times, on a series ofchips:

-   -   The attacker chooses the address A of a word in flash memory.    -   The attacker uses the FIB to set bits A₀ and A_(i) to P.    -   If the chip becomes unable to use the key K, then clearly the        word at address A was either in K or ˜K. That is,        A_(i)=K_(i+jW), or A_(i)=˜K_(i+jW), where (i+jW)<N. In this        case, the attacker records a hit. The attacker can also deduce        that bits A₀ and A_(i) were not both P. This can mean one of 2        things:    -   A₀ and A_(i) were different, and they were part of K or ˜K. This        implies that K_(j+jW)< >K_(jW), for some j. This happens ⅔ of        the time.    -   A₀ and A_(i) were both E, and they were part of K or ˜K. This        implies that K_(i+jW)=K_(jW), for some j. This happens ⅓ of the        time.    -   Otherwise the attacker records a miss.    -   The attacker would do well to discard the chip, whether or not        the chip failed. This is because there might be some silent        damage to the chip, that could interact in unexpected ways with        subsequent FIB attacks. It is safer to start each new experiment        with a new chip.

After T attempts, there will be a record of how many hits Hi wererecorded for bit i in the word size.

At the end of the experiment, the attacker has W−1 fractions H_(i)/T,one for each bit 1-W-1 in the flash memory's words.

If an attack hits bits K_(i+jW) and K_(jW), for some j, and those keybits are different, this will always cause a failure. If those key bitsare the same, this will cause a failure half the time, on average.

So the attacker should expect that

H_(i)/T=(N/M)×Sum(j=0 to k−1, (if (K_(i+jW)=K_(jW)) then ½ else 1))

where k is the number of elements in the aliased key group.

If we define B_(i)=(H_(i)/T)/(N/M), for i=1 to W−1, then the attackerfinds B_(i)=(k−1) for the case where key bit K_(i+jW)< >K_(jW), for j in0 to k−1. The attacker finds B_(i)=(k−1)/2 for the case where key bitK_(i+jW)=K_(jW), for j in 0 to k−1.

The attacker should try various combinations of K_(i) that make theseequalities true. This dramatically decreases the search space necessaryto compromise the key.

If the attacker cannot set a bit to P, but can set it to E, then anequivalent attack is possible.

Storing a key in arbitrary places in flash memory will slow but not stopa determined attacker.

The same methods of attack that work for keys in known locations workfor keys in unknown locations. They are slower, because they rely onstatistics that are confounded with the failures that occur because ofreasons other than corruption of keys.

A sufficient number of experiments will allow the attacker to isolatethe failures caused by differences in the value of the bits of keys,from other failures.

When keys are stored in flash, the key bits can be guarded by anincreasingly elaborate set of operations to confound attackers. Examplesof such operations include the XORing of key bits with random numbers,the storing of inverted keys, the random positioning of keys in flashmemory, and so on.

Based on previous discussion, it seems likely that this increasinglyelaborate series of guards can be attacked by an increasingly elaborateseries of FIB attacks. Note however, that the number of chip samplesrequired by an attacker to make a success likely may be prohibitivelylarge, and thus a previously discussed storage method may beappropriately secure.

The basic problem of the storing and checking of keys is that the bitsof the key-related entities (˜K, R, etc) can be directly correlated tothe bits of the key.

Assuming a single key, a method of solving the problem is to guard thekey bits using a value that has no correlation with the key bits asfollows:

-   -   R and X are stored in the flash memory where R is a random        number different for each chip, and X=K owf(R), where owf( ) is        a one-way function such as SHA1 (see [1]).    -   R and X may be stored at known addresses    -   For the program to use the key, it must calculate K=X owf(R)

The one-way function should have the property that if there is any bitdifference in the function input, there are on average differences inabout half of the function output bits. SHA1 has this property.

If an attacker modifies even a single bit of R, it will affect multiplebits of the owf( ) output and thus multiple bits of the calculated K.

This property makes it impossible to make use of multiple bit attacks,because if bit 0 and bit i of R are modified, this will affect onaverage N/2 bits of K, that may or may not include bits 0 and i. Theattacker cannot deduce any information about bits of K.

Similarly, if bit 0 and bit i of X are modified, the attacker is able totell if X₀ and X_(i) were both P in this particular chip, but this willgive the attacker no information about key bits K_(i), because theattacker will not know the whole of R, and hence the attacker doesn'tknow any bits of owf(R).

If the attacker is restricted to FIB attacks, it doesn't matter if R andX are stored in fixed known locations, because these FIB attacks cannotextract any information about K.

A chip may need to hold multiple keys in flash memory. For thisdiscussion it is assumed that a chip holds NumKeys keys, namedK[0]-K[NumKeys-1].

These keys can be held in a number of ways.

They can be stored as NumKey instances of any of the insecure keystorage algorithms discussed above. These key storage methods areinsecure for the storage of multiple keys for the same reasons that theyare insecure for the storage of single keys.

If the keys are stored as processed keys using the method introduced inSection 5 then there is an issue of how many random numbers are requiredfor same storage. The two basic cases are:

-   -   Processed keys are stored along with a single random number R as        X[0]-X[NumKeys-1], where X[i]=K[i] owf(R)        -   Processed keys are stored along with a set of random numbers            R[0]-R[NumKeys-1], in the form X[0]-X[NumKeys-1], where            X[i]=K[i] owf(R[i]).

Both storage techniques are immune to FIB attacks, as long as no keyshave been compromised.

If storage technique (1) is used, and an attacker knows one of the keys,then that knowledge can be used with a FIB attack to obtain the value ofanother keys and hence all keys. The attack assumes that the attackerknows:

-   -   the location of R and X[0]-X[NumKeys-1], where X[i]=K[i] owf(R).    -   the value of K[a], and wishes to discover the value of K[b].

For each bit i in the key K[b]:

-   -   The attacker uses the FIB to set R_(i) and X[a]_(i) to P,    -   If the chip still works when it uses K[a],        -   The attacker knows that R_(i) and X[a]_(i) in this            particular chip were originally P,        -   The attacker uses the FIB to set X[b]_(i) to P,        -   If the chip still works when it uses K[b], then the attacker            can deduce that X[b]_(i) was originally P, in which case            K[b]_(i) is 0.        -   If the chip no longer works when it uses K[b], then the            attacker can deduce that X[b]_(i) was originally E, in which            case K[b]_(i) is 1.    -   If the chip no longer works, then        -   repeat this procedure for K[b]_(i) with a new chip.

If the attacker cannot set a bit to P, but can set it to E, then anequivalent attack is possible.

The attack relies on the fact that even if the attacker does not knowthe value of R, the same value owf(R) is used to guard all of the keysand there is known correlation between corresponding bits of each X.

Note that if the locations of R and X[0]-X[NumKeys-1], are randomisedduring program insertion, it will slow but not stop this kind of attack,for the reasons described in Section 4.

Therefore storage technique (2) is more secure, as it uses a set ofdifferent owf(R[i]) values to guard the keys. However storage technique(2) requires additional storage over storage technique (1).

The problem with storage technique (1) is that there is a single value(owf(R)) used to guard the keys, and there is known correlation betweencorresponding bits of each stored form of key. i.e. XOR is a poorencryption function.

Storage technique (2) relies on storing a different R for each key sothat the values used to protect each key are uncorrelated on a singlechip, and are uncorrelated between chips. The problem with storagetechnique (2) is that additional storage is required—one R per key.

However, it is possible to use a single base-value such that thebit-pattern used to protect each K is different. i.e.: storage technique(3) is as follows:

-   -   Processed keys are stored with a single random number R in the        form X[0]-X[NumKeys-1], where X[i]=K[i] owf(R|i), where owf( )        is a one-way function such as SHA1.

For the program to use a key, it must calculate K[i]=X[i] owf(R|i).

The keys may be stored at known addresses.

In general, technique (3) stores X[i] where X[i]=Encrypt(K[i]) using keyQ. The Encrypt function is XOR, and Q is obtained by owf(R|i) where R isan effectively random number per chip. Normally XOR is not a strongencryption technique (as can be seen by the attack in Section 2.2), butit is strong when applied to an uncorrelated data, as is the case withthis method. The technique used to generate Q is such that uncorrelatedQs are obtained to protect the keys, each Q is uncorrelated from thestored R, and both Rs and Qs are uncorrelated between chips. It isn'tquite a pure one-time-pad, since the same stored R is used each time thekey is decrypted, but it is a one-time-pad with respect to the fact thateach Q is different on a single chip, and each R (and hence the Qs) isdifferent between chips.

The following terminology is now used:

A nonce is a parameter that varies with time. A nonce can be a generatedrandom number, a time stamp, and so on. Because a nonce changes withtime, an entity can use it to manage its interactions with otherentities.

A session is an interaction between two entities. A nonce can be used toidentify components of the interaction with a particular session. A newnonce must be issued for each session.

A replay attack is an attack on a system which relies on replayingcomponents of previous legitimate interactions.

In the generation of non-deterministic sequences, nonces are useful inchallenge-response systems to protect against replay attacks.

A entity, referred to as a challenger, can issue a nonce for each newsession, and then require that the nonce be incorporated into theencrypted response or be included with the message in the signaturegenerated from the other party in the interaction. The incorporation ofa challenger's nonce ensures that the other party in the interaction isnot replaying components of a previous legitimate session, andauthenticates that the message is indeed part of the session they claimto be part of.

However, if an attacker can predict future nonces, then they canpotentially launch attacks on the security of the system. For example,an attacker may be able to determine the distance innonce-sequence-space from the current nonce to a nonce that hasparticular properties or can be used in a man-in-the-middle attack.

Therefore security is enhanced by an attacker not being able to predictfuture nonces.

To prevent these kinds of attacks, it is useful for the sequence ofnonces to be hard to predict. However, it is often difficult to generatea sequence of unpredictable random numbers.

Generation of sequences is typically done in one of two ways:

-   -   An entity can use a source of genuinely random numbers, such as        a physical process which is non-deterministic;    -   An entity can use a means of generating pseudo-random numbers        which is computationally difficult to predict, such as the Blum        Blum Shub pseudo-random sequence algorithm [1].

For certain entities, neither of these sources of random numbers may befeasible. For example, the entity may not have access to anon-deterministic physical phenomenon. Alternatively, the entity may nothave the computational power required for complex calculations.

What is needed for small entities is a method of generating a sequenceof random numbers which has the property that the next number in thesequence is computationally difficult to predict.

At a starting time, for example when the entity is programmed ormanufactured, a random number called x₀ is injected into the entity. Therandom number acts as the initial seed for a sequence, and should begenerated from a strong source of random numbers (e.g. anon-deterministic physically generated source).

When the entity publishes a nonce R, the value it publishes is a strongone-way function (owf) of the current value for x: i.e:

R=owf(x)

The strong one-way function owf( ) can be a strong one-way hashfunction, such as SHA-1, or a strong non-compressing one-way function.

Characteristics of a good one-way function for this purpose are that it:

-   -   is easy to compute    -   produces a sufficiently large dynamic range as output for the        application    -   is computationally infeasible to find an input which produces a        pre-specified output (i.e. it is preimage resistant). This means        an attacker can't determine x_(n) from R_(n).    -   is computationally infeasible to find a second input which has        the same output as any pre-specified input (i.e. it is        2nd-preimage resistant).    -   produces a large variance in the output for minimally different        inputs    -   is collision resistant over the output bit range i.e. is        computationally infeasible to find any two distinct inputs x₁        and x₂ which produce the same output

The number of bits n in x needs to be sufficiently large with respect tothe chosen one-way function. For example, n should be at least 160 whenowf is SHA-1.

To advance to the next nonce, the seed is advanced by a simple means.For example, it may be incremented as an n-bit integer, or passedthrough an n-bit linear feedback shift register.

The entity publishes a sequence of nonces R₀, R₁, R₂, R₃, . . . based ona sequence of seeds x₀, X₁, X₂, x₃, . . . .

Because the nonce is generated by a one-way function, the exportedsequence, R₀, R₁, R₂, R₃, . . . etc., is not predictable (ordeterministic) from an attacker's point of view. It is computationallydifficult to predict the next number in the sequence.

The advantages of this approach are:

-   -   The calculation of the next seed, and the generation of a nonce        from the seed are not computationally difficult.    -   A true non-deterministic number is only required once, during        entity instantiation. This moves the cost and complexity of the        difficult generation process out of the entity.    -   There is no need for a source of random numbers from a        non-deterministic physical process in the running system.

Note that the security of this sequence generation system relies onkeeping the current value for x secret. If any of the x values is known,then all future values for x can be predicted and hence all future Rvalues can be known.

Note that the random sequence produced from this is not a strong randomsequence e.g. from the view of guaranteeing particular distributionprobabilities. The behaviour is more akin to random permutations.Nonetheless, it is still useful for the purpose of generating a sequencefor use as a nonce in such applications as a SoC-based implementation ofthe QA Logical Interface.

In one embodiment, functionally identical code segments are stored ineach of multiple devices. The device can be, for example, a series ofprinter cartridges, and more specifically the QA printer chip attachedto such cartridges.

The programs stored in the devices are functionally identical to eachother, which is to say that they implement the same instructions in thesame way, although the individual instances of the programs may operateon different data and using different keys.

Whilst the program instances are functionally identical, they are brokenup into code segments that are each stored at different locations in theflash memory. For convenience, each code segment can be a function orother relatively self-contained subset of instructions, although this isnot required.

After the chip has been manufactured, the program code is injected suchthat the position of particular code segments varies across the devices.The memory location at which each code segment starts can be selected inany convenient manner. It is not strictly necessary that every segmentbe placed in a truly random or unique location in the memory from deviceto device. Rather, it is enough that a potential attacker cannot rely onthe same code being in the same place in a series of differentintegrated circuits.

It is still, however, desirable that the location of particular codesegments be selected at least pseudo-randomly, and preferably randomly.

In the preferred embodiment, an initial instruction is located at aninitial memory location that is the same across all of the devices. Thismeans that a common boot program can be used at startup, since it alwayslooks to the initial location to commence the program. Somewhere in thecode segment following the initial location, the program jumps to one ofthe random or pseudo-random memory locations. From this point in theprogram, the instructions are effectively unknown to an attacker. Ofcourse, it is possible that only a relatively small (but preferablyimportant) code section is located at this random or pseudo-randomlocation. The rest of the code can be at common locations across thedevices.

The reference to the random or pseudo-random location in the programcode can be explicit (as above) or implicit. For example, the programcode can refer to a pointer or register that contains the location ofinterest. The location is stored in the pointer or register duringprogram instantiation. The location of interest can also be stored in ajump table.

Multiple random or pseudo random locations can be used. The program canjump to multiple locations during its execution, each of the locationsbeing different across several devices. The code segments themselves canbe different to each other, such that even the segments themselves (innumber or size) vary from device to device.

Terms: A number of terms are used in the specification and claims. Thefollowing list includes some definitions that are to be used when theseterms appear, unless a contrary meaning is clearly intended in context:

“Relatively unique”—Depending upon the context, this phrase generallymeans that a value or bit-pattern is rarely repeated across multipledevices. It is usually preferable that the value or bit-pattern isselected in a random or at least pseudo-random way. However, in someapplications it is sufficient to ensure that the value or bit-pattern ismerely not frequently repeated from device to device. Sometimes, arelatively small number of potential values or bit-patterns will besufficient to make attacking a chip or other device sufficiently hardthat it will not be worth attempting

“Associated with a base key”—A variant key is associated with a base keywhen it is the result of applying a one way function to the base key anda bit-pattern.

“Cryptographically strong”—Whilst this is a relative term, it has someuse when comparing the ease with which functions can be broken when usedin cryptography. For example, an XOR function, whilst useful in somecircumstances in cryptography, is considerably easier to “crack” than,say, a hash function or sufficient length. Also, a hash functioncombined with a key into a MAC (i.e. “message authentication code”) suchas HMAC-SHA1 used with a certain length of key will be cryptographicallystronger if the key length is increased, up to a certain length of key.

“Bit-pattern”—A generic term that can refer to keys, nonces, randomnumbers, pseudo-random numbers, serial numbers, and any other strings ofinterest.

“Functionally identical”—Code segments that are functionally identicaloperate in the same way, using the same functions and subroutines aseach other where each of the functions and subroutines are alsofunctionally identical. However they may use different keys, constantsor variables, and/or operate on different stored data or data andprogram segment code stored at different locations in memory. Forexample, two functionally identical code segments may each load aparticular constant into a register for use in evaluating an expression,and although the order of steps taken to load the constant may differbetween segments, the value of the constant may differ between segments,and the address of the constant in memory may differ between segments,the functional intent of the code segment is the same for both.

It will be appreciated by those skilled in the art that the foregoingrepresents only a preferred embodiment of the present invention. Thoseskilled in the relevant field will immediately appreciate that theinvention can be embodied in many other forms.

1. A method of enabling or disabling a verification process of a firstentity in response to a predetermined event, the first entity having atleast one associated bit-pattern and at least one variant key, each ofthe variant keys having been generated by applying a one way functionto: a base key; and one or more of the at least one bit-patterns,respectively; or one or more alternative bit patterns, each of thealternative bit-patterns being based on one of the at least onebit-patterns, the method comprising: (a) determining that thepredetermined event has happened; and (b) enabling or disabling at leastone of the first variant keys in response to the predetermined event. 2.A method according to claim 1, wherein step (a) includes disabling atleast one of the variant keys, such that the disabled at least onevariant key can no longer be used to digitally sign information in thatentity.
 3. A method according to claim 1, wherein step (a) includesdisabling at least one of the variant keys, such that the disabled atleast one variant key can no longer be used to verify information signedby one or more respective base keys related to the disabled at least onevariant key in that entity.
 4. A method according to claim 1, whereinthe step of disabling the at least one variant key includes modifying astatus of a flag associated with that at least one variant key.
 5. Amethod according to claim 1, wherein the step of disabling the at leastone variant key includes deleting that at least one variant key.
 6. Amethod according to claim 1, wherein the step of disabling the at leastone variant key includes modifying that at least one variant key
 7. Amethod according to claim 1, wherein the event is a predetermined pointin time being reached or passed.
 8. A method according to claim 1,wherein the first entity includes a plurality of the variant keys, theplurality of variant keys being based on the result of a one wayfunction applied to: a respective one of a corresponding plurality ofbase keys; and one of the at least one bit-patterns or one of the atleast one alternative bit-patterns, the method comprising: determiningthat a predetermined event related to one of the variant keys hashappened; and enabling or disabling at least one of the plurality ofvariant keys with which the predetermined event is associated.
 9. Amethod according to claim 1, wherein each base key has a correspondingsequence of predetermined events associated with them, the methodincluding the steps of: (a) determining that one of the predeterminedevent has happened; and (b) enabling or disabling the variant key in thesequence corresponding to predetermined event that is determined to havehappened.
 10. A method according to claim 9, wherein the variant keysare disabled in the order of the sequence of predetermined events.
 11. Amethod according to claim 10, wherein the sequence of events ischronological.
 12. A method according to claim 11, wherein each of theevents includes a time being reached.
 13. A method according to claim12, wherein the step of determining that one of the events has happenedincludes receiving a time from a trusted source.
 14. A method accordingto claim 13, wherein the time is a date.
 15. A method according to claim14, wherein the date is determined with a resolution of a month.
 16. Amethod according to claim 2, wherein the predetermined event includesdetection of compromise of one or more of the variant keys, the methodcomprising disabling the one or more variant keys detected ascompromised.
 17. A method according to claim to claim 2, wherein thepredetermined event includes suspect compromise of one or more of thevariant keys, the method comprising disabling the one or more variantkeys suspected of being compromised.